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1. Introduction 

This report documents the results of research and development work performed by Rockwell 
Collins in addressing the Task 1 objectives under NASA Contract NNL12AA11C. Under this 
contract Rockwell Collins provided analytical support to the NASA Langley Research Center 
(LaRC) in NASA’s development of a Traffic Aware Strategic Aircrew Requests (TASAR) flight 
deck Electronic Flight Bag (EFB) application for technology transition into operational use. 

The two primary objectives of this contract were for Rockwell Collins and the University of Iowa 
OPE to 1) perform an implementation assessment of TASAR toward early certification and 
operational approval of TASAR as an EFB application (Task 1 of this contract), and 2) design, 
develop and conduct two Human-in-the-Eoop (HITE) simulation experiments that evaluate 
TASAR and the associated Traffic Aware Planner (TAP) software application to determine the 
situational awareness and workload impacts of TASAR in the flight deck, while also assessing the 
level of comprehension, usefulness, and usability of the features of TAP (Task 2 of this contract). 
This report represents the Task 1 summary report. The Task 2 summary report is provided in [0]. 

1.1 Background and Motivation for TASAR 

The development of technologies such as TASAR support the objectives of the former NASA 
Airspace Systems Program (ASP) and its NextGen Concepts and Technology Development (CTD) 
Project, as well as the new NASA Airspace Operations and Safety Program (AOSP). The NextGen 
CTD Project developed innovative concepts and technologies to improve the efficiency, capacity, 
and safety of the National Airspace System. Research focus areas included traffic flow 
management, dynamic airspace configuration, separation assurance, super density operations, and 
airport surface operations. In the area of separation assurance, CTD research included the 
development of advanced concepts and technologies for aircraft to provide their own traffic 
separation services, i.e. airborne separation, using Automatic Dependent Surveillance Broadcast 
(ADS-B). 

CTD research produced advanced algorithms for detecting and resolving traffic conflicts in the 
presence of weather and time constraints. Leveraging this far-term research, NASA envisions a 
near-term application of this advanced flight-deck technology to improve pilot-initiated requests 
for trajectory change(s) made to Air Traffic Control (ATC) in today’s operations. In a concept 
called “Traffic Aware Strategic Aircrew Requests” (TASAR), pilots would use onboard 
automation tools to identify trajectory improvement opportunities that are deconfiicted from traffic 
aircraft, i.e., traffic aware, and also aware of environmental constraints, e.g., weather, winds, 
airspace constraints, that may adversely affect their flight route, prior to making the trajectory- 
change request to Air Traffic Control (ATC). 


1 


The TASAR capability is anticipated to increase ATC approval frequency and therefore achieve 
benefits in areas such as flight efficiency, flight schedule compliance, passenger comfort, and pilot 
and controller workload. With TASAR, NASA intends to help accelerate the adoption of 
networked flight-deck automation systems and ADS-B equipage by the aircraft operator 
community. 

1.2 Contract Objectives 

The objectives of this contract were to 1) analyze and assess the implementation requirements for 
certification and operational approval of TASAR (Task 1 of this contract and addressed by this 
report) and 2) to assess human factors including pilot workload and situational awareness 
associated with the TASAR flight-deck technology (Task 2 of this contract, but addressed in a 
separate summary report [0]). By analyzing the implementation requirements and assessing pilot 
use of the TASAR capability in simulation, the path to implementation for operational use can 
possibly be shortened. NASA Contract NNL12AA1 1C was awarded to Rockwell Collins and its 
subcontractor, the University of Iowa Operator Performance Laboratory (OPL), for these tasks 
under the NASA Headquarters Aeronautics Research Mission Directorate (ARMD) NASA 
Research Announcement (NRA) entitled “Research Opportunities in Aeronautics” - 2010, 
Amendment 7, NextGen CTD Project, Subtopic 5. 

1.3 Organization of this Report 

Section 1 of this report presents an introduction and context for the research. Section 2 provides 
an overview and high-level description of the TASAR EFB application and summarizes the high- 
level results of this assessment. The research objectives for Task 1 of this contract and documented 
in this report are identified in Section 3 and the attendant research results are provided in Section 
4. Due to the expansive nature of regulatory documents that apply to EFB applications, a number 
of appendices are provided that capture the TASAR-specific certification and operational approval 
requirements and provide some artifacts that were developed that may be used in gaining early 
operational approval for TASAR. 

The certification and operational approval analyses included the development and analysis of a 
TASAR User Community Survey of end users, including pilots, dispatchers and flight operations 
personnel, to gain their perspectives and needs for the capabilities offered by TASAR. An 
operational hazard assessment of TASAR was made in order to determine the Failure Effects 
Classification (FEC) of TASAR, which plays a significant role in determining the extent of 
certification and operational approval requirements that must be addressed. EFB industry 
standards adherence requirements were identified for TASAR and a detailed review of FAA 
guidelines and regulatory requirements were made. A certification plan for TASAR was developed 
for future TASAR approval. Certification and operational approval requirements were identified 
and underwent review with in-house Designated Engineering Representatives (DERs) as part of 
an approval “Dry Run.” NASA and Rockwell Collins then met with key decision makers at FAA 
in a technical interchange which validated our analysis findings provided in Section 4. 


2. TASAR Overview and High-Level Description 

The TASAR EFB application is currently being developed by NASA in order to leverage emerging 
flight deck technologies for cost benefits to current flight operations. The TASAR operational 
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concept is described in [1] and [2] with the TASAR applieation deseription found in [3]. Reference 
[4] describes NASA’s work in developing TASAR as a near-term, low-cost application. Reference 
[2] also provides a deseription of TASAR operational scenarios. A preliminary benefits assessment 
of TASAR is found in [5]. Sereen shots of Version V2 of the TASAR Human Maehine Interface 
(HMI) design are provided in [3]. An overview of the operational safety and eertifieation 
assessment of TASAR is provided in [6] with a detailed operational hazards and safety 
requirements analysis of TASAR provided in [7]. 

Among the systems technologies that comprise or support TASAR are flight-optimizing software 
algorithms, a software hosting device sueh as a Portable Eleetronie Device (PED) EEB, ADS-B 
IN and other sourees of traffic information, and additional airborne sensor data and ground-based 
information via data link, internet connectivity, etc. TASAR seeks to provide eost-benefieial 
optimization with respeet to the current flight plan, taking traffic and other eonstraints into aecount. 
Using these information sourees, the TASAR application has the ability to react in an agile manner 
to ehanges in the airspaee environment (e.g., adverse weather, winds, airspaee constraints, and / or 
improved timeliness and accuraey of information about factors that affect the aircraft’s execution 
of its flight plan). 

TASAR employs a flight deck-based applieation that seeks to identify and reeommend trajectory 
improvement opportunities to the pilot that have a high probability of approval by ATC. Utilizing 
available information of own-ship flight status/plan and airspaee environment (e.g., proximate 
traffie, weather, winds, ATC system status, etc.), the TASAR applieation seeks to identify and 
reeommend candidate trajeetories for consideration by the pilot that have higher probability of 
ATC approval. The pilot, at his or her diseretion, can choose to issue a ehange request to ATC 
based on TASAR reeommended trajectory change candidates. 

Prior to recommending trajeetory ehange candidates to the pilot, TASAR uses available on-board 
traffie data to account for potential conflicts. It uses weather and restrieted airspaee data to avoid 
these hazards. It may also aeeount for known ATC rules to inerease likelihood of approval. Thus, 
reeommended trajeetory ehange request eandidates from TASAR to the pilot are expeeted to have 
the following eharaeteristics that will eneourage inereased pursuit of flight plan improvements by 
the pilot from ATC via change requests: 

1) Provide ongoing optimization of the flight plan in terms of time and / or fuel savings or 
other desired attributes such as passenger comfort. 

2) Meet operational goals for the flight, as provided by pilot preferenee inputs 

3) Have a high potential for approval by ATC by considering ATC constraints in the 
identification process 

TASAR trajeetory change request candidates are advisory-only to the pilot, and the pilot has full 
discretion on whether or not to select a TASAR-provided trajectory change for a subsequent 
ehange request to ATC. Pilot training ensures that the pilot’s priorities (aviate, navigate, and 
eommunieate) and proper eoordination with ATC, (e.g., ehange requests) are followed as in 
today’s operations. The pilot has responsibility to evaluate TASAR-provided trajeetory ehange 
eandidates for operational aeeeptability before making a change request to ATC. 

As in today’s operations, ATC has separation responsibility and is authorized to deny ehange 
requests from the pilot that do not meet ATC constraints and requirements. TASAR makes no 
ehanges to the rules and proeedures that govern the interaetions between pilots and controllers. 
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Summary of TASAR Research Results from this Contract 

As described below in the main body of this report, the TASAR EFB application was analyzed in 
detail against applicable FAA regulatory documents to determine certification and operational 
approval requirements that must be met to gain approval for use as an advisory decision support 
tool to the flight crew. Operational hazard analyses were conducted to determine the TASAR 
Failure Effects Classification (FEC) and associated safety requirements. The results of these 
analyses were presented to FAA certification (AIR) and operational approval (AFS) authorities by 
NASA and Rockwell Collins as part of an information meeting held at the FAA office. The FAA 
AIR and AFS authorities concurred with the findings of our certification and operational approval 
requirements analysis and confirmed that the TASAR EFB application would be considered for a 
Class 2 EFB and be representative of a Type B application. They also noted that the TASAR 
application would be approvable using a “Minor Effect” FEC due to potential workload 
considerations and would warrant a “No Effect” designation from a loss of function perspective. 

For software and hardware-specific approval requirements, FAA concurred that there are no 
software airworthiness approval requirements for TASAR as a standalone application. TASAR, as 
a standalone application, does not require DO-178B compliance in its development even for a 
Design Assurance Fevel D. Some software-specific requirements will need to be addressed if 
TASAR is hosted on a platform that is also hosting other certified applications. 

The majority of certification-related compliance requirements for the TASAR EFB system fall 
into the hardware domain. Airworthiness regulations apply to installed EFB components and do 
not apply to the portable EFB components, including internal components of the EFB. For TASAR 
this primarily involves the installed components related to mounting (size and weight), power 
(maximum electrical load, voltage, and current frequency), and data connectivity (input/output 
data specifications and security). Software and hardware-specific requirements are discussed in 
detail in the body of this report. 

In addition to the analyses of certification and operational approval requirements leading to future 
approval of the TASAR application by FAA, this contract also developed and performed two HITE 
human factors experiments using the TASAR EFB application integrated in the University of Iowa 
OPE Boeing 777 simulator. The goal of these HITE studies was to determine via objective and 
subjective measures the impact of TASAR on the conduct of flight operations (including non- 
normal situations), as well as to evaluate the HMI at two stages in its design. The development, 
execution, and analyses of the two HITE simulation experiments represents Task 2 of this contract 
and are provided in a separate document [0]. 


3. Research Tasks and Activities 

This section identifies the specific research tasks and associated activities that were performed in 
Task 1 of this contract. The objectives of Task 1 were to perform analyses and assessment of the 
TASAR EFB application to support its near-term implementation, i.e., to gain early certification 
and operational approval of TASAR by FAA approval authorities. 

The implementation assessment tasks and activities described in this report are intended to 
generate guidance that ensures that all preparatory research and development by the TASAR team 
(NASA, Rockwell Collins and OPE, and other TASAR contractors) have maximum applicability 
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toward enabling the near term implementation of TASAR. The deseription and results of these 
activities are documented in Section 4. 

The analyses and assessments performed and documented herein identify the requirements for 
equipment certification, operational approval, and user / FAA acceptability for entering TASAR 
into operational service. They serve to refine the TASAR concept in collaboration with NASA 
and other TASAR contractors by engaging the user community and the FAA, subsequently lead 
to strategies and requirements for implementation of the TASAR concept. 

The following represent the research activities performed in support of Task 1 of this Contract; 

1. User Community Survey (see Section 4.1 for details) 

a. Design a User Community Survey on current aircraft-operator practices for 
improving trajectories while aircraft are en route (Section 4.1.1) 

b. Review results of NASA’s preliminary data analysis; provide additional findings and 
recommendations for the TASAR concept and implementation strategies that would 
accelerate user adoption of TASAR (Section 4. 1 .2) 

2. Certification and Operational Approval Requirements (see Section 4.2 for details) 

a. Analyze TASAR for comprehensive operational hazards. Define and document 
safety requirements to mitigate the operational hazards (Section 4.2.1) 

b. Determine TASAR requirements for adherence to industry standards for aircraft 
systems development and EFB devices; determine and document the specific design, 
development, test, validation, and approval requirements necessary for entering 
TASAR into operational service (Section 4.2.2) 

c. Analyze TASAR with respect to FAA guidelines and regulatory requirements for 
certification and operational approval; determine the most appropriate and efficient 
methods and processes for pursuing certification and operational approval, and 
produce a corresponding detailed plan (Section 4.2.3) 

d. Develop representative TASAR artifacts for certification and operational approval 
processes. “Dry run” these processes with in-house Designated Engineering 
Representatives (DER). Document the review process, the DER’s feedback, and the 
associated changes to the artifacts and processes (Section 4.2.4) 

e. Determine the additional certification and operational approval requirements, if they 
exist, of the TAP HMI Version 4 as a “delta” analysis to the findings of the 
certification and operational approval requirements analyses (Section 4.2.5). 

3. Engage the EAA community in coordination with NASA, including the directorates 
responsible for certification and operational approval, to research EAA guidance for 
entering TASAR into operational service (Section 4.3). 


4. Research Program Description and Documentation of Results 

This section provides a detailed description of the research activities conducted in Task 1 and the 
results of this research. Research results focus on the implementation assessment of TASAR and 
identify certification and operational approval requirements and artifacts that can be used toward 
gaining EAA approval. 
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4.1 User Community Survey 

As part of its development of the TASAR applieation, NASA tasked Rockwell Collins to develop 
a user community survey of key stakeholders in order to gain insight into their operations to inform 
the development of the TASAR application. Rockwell Collins developed the initial draft survey 
and then worked jointly with NASA and a contractor subject matter expert to collaboratively refine 
and further develop the survey that was then used by NASA in engaging the operators. Three 
aircraft operators were surveyed representing 1) a major network carrier (i.e., global operator), 2) 
a domestic low-cost airline, and 3) a fractional operator of business aircraft. Surveyed within these 
operators were pilots, dispatchers, and flight operations personnel. The surveyed operators 
represent a relatively broad spectrum of potential users of TASAR. 

4.1.1 TASAR User Survey Overview 

The goal of the TASAR survey was to solicit information from potential end users of TASAR 
concerning their current flight operations, with specific focus on flight planning and re-planning 
in today’s airspace operations. The survey requested information on a notional flight in terms of 
“challenges” and their frequency of occurrence during flight operations and flight re-planning in 
the presence of changing conditions affecting the flight. The survey requested response on 
available support tools, information sources utilized, and their effectiveness (i.e., well-served or 
under-served) in achieving efficient flight operations. The survey also sought information on 
current and planned avionics equipage of operator fleets that are closely aligned with the type of 
capabilities associated with TASAR. 

The survey included questions directed at various stakeholders within each operator organization, 
including pilots, dispatchers, and flight operations personnel. Tables 1, 2, 3, and 4 summarize 
survey questions in tabular format. NASA provided a consolidated data set of survey results that 
integrated the individual responses from each stakeholder survey. Approximately 12 pilots and 12 
dispatchers responded from the three operators surveyed. It was this consolidated data set that was 
reviewed in order to provide the observations and recommendations that will be discussed in the 
next section (Section 4. 1 .2). 

The TASAR User Community Survey consisted of four sections. The initial section, summarized 
in Table 1, represents survey topics that focused on the demographics of the operator. Table 2 
represents survey topics requested from the pilot community of the operator. Table 3 summarizes 
the survey topics that pertained to dispatchers, and Table 4 lists survey topics addressed to the 
operator’s flight operations. 


Table 1 Operator Survey Questions by Category - Operator Demographics 


Survey Topic 

Operator 

Demographics 

Category 

Detail 

Type of Operator 

E.g. major air carrier, domestic airline, 
fractional operator, etc. 

Aircraft fleet size 

<10, 11-49, 50-99, 100-500,>500 aircraft 

Fleet mix 

Type / make of aircraft 

Stage Length 

Short haul (<2 hr. flight), medium haul (2 to 4 
hr.), long haul (greater than 4 hrs.) 

Typical flight departure and arrival 
airports 

Hub, non-hub airport 

Number of active pilots 


Peak airborne number of flight 
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Number of dispatchers 


Number of dispatchers on duty during 
peak operations 


party in-flight optimization 

Not for flight planning, but service support 
during flight 


Table 2 Operator Survey Questions by Category - Pilots 


Survey Topic 


Category 

Detail 


Years of experience 



Flight categorization by level of 
challenge 

Percentage of flights viewed as minimally, 
moderately, or extremely challenged - level of 
disrupted operations due to environmental 
factors, e.g., weather, adverse winds, airspace 
disruptions, traffic delays, security event 


Estimated impact in terms of fuel burned 
and flight time of “actual” flight when 
compared to “original” pre-departure 
flight plan 

Under various challenge levels (minimally, 
moderately, extremely challenging flight 
conditions) 


Impact of ATC constraints on operational 
efficiency 


Pilot Survey 

Questions 

In-flight re -planning capabilities 

available to pilots 

E.g., Flight Management System (FMS), 
automation / manual cockpit tools, company 
provided, 3'^'^ party provided, other 

Effectiveness of in-flight re -planning 
capabilities 

• Provided by dedicated company personnel - 
without tools; with tools 

• Provided by automated monitoring, advisory 
service-company resource; party 

• Achieved by pilot, with tools 



Typical number of change requests per 
flight 

Function of stage length 


Types of change requests during en-route 
operations 

E.g., change requests for altitude, heading, 
lateral route, speed, or combination 


Level of coordination of change requests 
with dispatcher 

Percentage of change requests coordinated 
with dispatcher 


Type of coordination of change requests 
with dispatcher 

Initiation and coordination of change request 
with/without dispatcher 


Type and Frequency of action by ATC in 
response of change request 

E.g., immediately approved, cleared after 
standby, etc. 


Reasons for denial of change request 

E.g., traffic, traffic congestion, weather 
routing, metering, controller workload, other 


4.1.2 Survey Results, Findings, and Recommendations 

This section provides an overview of the review and assessment of received TASAR survey 
responses and NASA’s preliminary consolidation and analysis of these responses. The objective 
of the analysis performed by Rockwell Collins was to determine findings and recommendations 
for the TASAR concept and implementation strategies that would accelerate user adoption of 
TASAR. Detailed results of the TASAR User Survey analysis are found in Appendix A. 

Recommendations and observations derived from the analysis of TASAR user survey responses 
fall into two categories as follows; 

1) Equipage for TASAR 
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2) TASAR cost benefits, usability, and synergy with dispateh and ATC processes. 


Table 3 Operator Survey Questions by Category - Dispatcher 


Survey Topic 



Category 

Detail 


Years of experience 



Average number of flights managed per 
dispatcher 



Peak number of flights managed per 
dispatcher 



Organizational policies and procedures 

With respect to level of empowerment for pilot 
to perform flight re-planning 


Automation tools for monitoring flight 
efficiencies 

Available automation tools 


Adverse factors affecting original flight 
plan 

Adverse weather, metering, etc. 


Constraint factors affecting flight re- 
planning 

Connecting flight, fuel reserve, lack of 
sufficient information on flight or airspace 
status, lack of accurate and timely weather 
information, etc. 


Available flight planning capabilities 

Company provided with/without tools, 
company automated monitoring, 3^*^ party 
automated monitoring, etc.) 



Accurate convective weather forecasts, wind 

Dispatcher Survey 
Questions 

Information sources for Dispatch support 

speed / direction / temperature, airspace status, 
airport facility status / weather / traffic 
information 


Priority ranking of information sources 
for Dispatch support 



Effectiveness of information sources for 
Dispatch support 



Comments on areas lacking and 
insufficient information for dispatch 



Comments on areas of information 
source improvement 



Time spent on flight optimization 



Effectiveness of current flight 

Under various levels of challenged flights 


optimization capabilities 

(minimally, moderately, extremely challenged) 


Level of flight planning constraint 
impacts in being able to achieve desired 
(unconstrained) flight 



Reason for flight re -planning by dispatch 

In-flight emergency, equipment failure, low 
fuel reserve, significant weather, etc. 


Time savings threshold for initiating an 
en-route re-plan 



Fuel savings threshold for initiating an 
en-route re-plan 



4.1.2. 1 Equipage for TASAR 

Based on survey responses from the three operators surveyed, a favorable finding is that from an 
equipage perspective, the operators surveyed in many eases are beginning to equip with the type 
of avionics systems and assoeiated EFB and data communication capabilities needed to enable 
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TASAR. ADS-B OUT (primarily 1090 MHz), EFB Class (1, 2 or 3), internet access (via terrestrial 
and/or satellite networks) and data communications (Aircraft Communications Addressing and 
Reporting System (ACARS), Controller Pilot Data Link Communications (CPDLC)) are already 
in their plans. ADS-B IN (1090 MHz and/or Universal Access Transceiver (UAT)) plans are 
considerably less certain. 


Table 4 Operator Survey Questions by Category - Flight Operations 


Survey Topic 

Flight Operations 
Survey Questions 

Category 

Detail 

Avionics equipage current and plans 
(today, in 2 years, by 2020) 

• ADS-B Out 

• ADS-B IN 

• 1090 MHz, UAT 

• EFB Class (1,2, and/or 3) 

• EFB Operating System (Windows, Linux, 
iOS 

• Internet Access - terrestrial and / or satellite 
based 

• Data Communications via ACARS 

• Data Communications via CPDLC 

Priority rating of cost factors affecting 
flight path performance 

Fuel, flight time, schedule integrity, ride 
quality, other 

Level of costliness of cost factors 


Revenue impact sensitivity rating for 
operational factors 

E.g., on-time performance, fuel efficiency, ride 
quality, other 

Rating of level of disruptiveness of flight 
factors 

E.g., poor forecast of winds, airspace 
disruptions, etc. 

Assessment of actual versus original 
flight plan performance 

With respect to flight time, fuel burned, on- 
time arrival 

Factors that adversely affect performance 

Weather, metering, etc. 

Company constraints to be consider by 
pilots when initiating en route flight re- 
planning. 

E.g., arrival sequence with other organization 
flights, gate availability, critical connections, 
requirement for fuel stop, etc. 


In this regard, the Fractional Operator, with its fleet of business and regional aircraft, is already 
well equipped with data connectivity to ground systems. The two airline (air transport) operators, 
particularly the Global Network Carrier, are more reliant on ACARS and data communications 
and are currently not as connected to internet data networks, but this is improving. It is 
recommended that data connectivity be strongly encouraged for all operators to provide the most 
effective information access for TASAR. While TASAR’ s traffic awareness is highly desirable, a 
prolonged period of mixed ADS-B equipage (both ADS-B OUT and ADS-B IN) is likely a reality 
for several more years, with the ADS-B OUT mandate in the United States not becoming a 
requirement until 2020. Cost benefits that can be gained from TASAR may help with this, but 
these must be fairly significant to create the pull for ADS-B IN equipage on their own. More likely, 
additional beneficial ADS-B applications for NextGen will need to assist with this pull. 

The most significant and encouraging finding is that the operators surveyed, representing a 
significant cross-section of aircraft operators, are beginning to have avionics and associated EFB 
and data communications capabilities capable of supporting early introduction of TASAR. 
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4.1. 2. 2 TASAR Cost Benefits, Usability, Synergy with Dispatch &ATC Processes 

In order to achieve a positive business case for TASAR, two key requirements must be achieved: 

1) Access to relevant, quality (i.e., accurate, timely {sufficient update rates, sufficient 
latency}) information sources (both ground-based and flight-deck based) 

2) Synergistic integration of TASAR with available flight (re)planning tools and processes 
used by dispatchers and pilots, while also being consistent with Air Traffic Control 
processes (i.e., change requests, traffic flow management including arrival flows). 

Without sufficient quality and completeness of information, TASAR is unlikely to provide reliable 
cost benefits. Pilot acceptance of TASAR is likely dependent on TASAR providing consistent and 
believable trajectory change recommendations with the indicated savings in fuel and/or flight time 
being actually achieved. In the longer term, TASAR’s utility should be integrated in a consistent 
manner with other flight planning and flight optimization processes utilized by Dispatch and 
should be consistent with ATC processes and procedures. 

While initial studies indicate the benefits of TASAR [5], a thorough assessment of TASAR cost 
benefits is likely required. Current on-going and planned flight simulations (University of Iowa 
OPL pilot evaluations in the use of TASAR using a Boeing 777 simulator), flight trial (Advanced 
Aerospace Solutions, LLC flight evaluation of TASAR using their Piaggio Avanti PI 80 aircraft), 
and ongoing research by NASA can assist in development of the TASAR business case. 

The following, in no particular order, represent the collection of general observations and 
comments identified regarding current flight planning and in-flight re-planning procedures, tools, 
information sources and their effectiveness (or lack thereof) as determined from survey responses 
from pilots, dispatchers, and flight operations personnel from the operators surveyed: 

1) From a Dispatch perspective, significant weather as observed by Dispatch or per notifica- 
tion from the pilot or ATC is the primary reason for re-planning of the flight. Airspace 
disruption notification from ATC follows weather as the next key factor for re-planning. 

2) Dispatchers rate the effectiveness of current flight optimization capabilities (and the 
available time to perform those duties) as moderately effective (4+ of 7, with 7 being most 
effective). These capabilities were slightly more effective for “minimally impacted” flights 
and slightly worse for “extremely impacted” flights due to adverse environmental factors. 

3) Weather is a primary consideration for dispatchers, with ATC constraints, airspace 
disruptions and constraints being a somewhat secondary factor (still important but not at 
the level of weather). Conversely, for pilots, ATC constraints and airspace disruptions are 
a larger factor, with en route weather being a secondary, less constraining factor in in-flight 
re-planning. 

4) Tools provide a range of strategic and tactical capabilities with respect to monitoring flight 
efficiencies. Tactical tool capabilities seem to focus on Dispatch gaining access to a 
specific aircraft’s Flight Management Computer (FMC) for position reports and associated 
flight parameter data and do not appear to provide a tactically integrated view of flight 
operations. TASAR has the ability to provide a more integrated tactical view from the 
specific own ship’s perspective, factoring in environmental constraints with respect to the 
current flight path. 
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5) Timeliness, accuraey, and breadth of information must continue to improve to enable eff- 
ective flight re-planning. At the same time, information management is required to avoid 
dispatcher information overload of excessive information detail and rapidity of updates. 
This requires intelligent automation to support dispatchers to allow them to manage the 
planning and re -planning of flights while keeping workload at reasonable levels. 

6) It is evident that both dispatchers and the pilot can benefit from improved information, 
particularly related to weather. Airspace information seems to be less of a factor. TASAR 
likely plays a tactical role in re-planning of the flight, while the role of Dispatch is more 
strategic. 

7) From pilot survey inputs concerning use of tools it is noted that tools are generally 
employed. Without tools, any support is not viewed as effective: 

a. Hands-on company support is used significantly (80+ %) and is moderately to very 
effective. Automated monitoring and advisory services are used less frequently but 
when used, are effective. Most pilots (80%) do not use 3'^‘^-party automated 
monitoring and advisory service support. Effectiveness was rated best for the more 
impacted flights (extremely and moderately challenged) due to adverse 
environmental conditions. 

b. Pilot in-flight re-planning with tools is heavily used (90%) and very to moderately 
effective (used a bit less when extremely challenged - perhaps due to pilot 
workload). Without tools, pilots still attempt to try to consider re-planning, but only 
with somewhat effectiveness at best. 

c. Survey results and insight into the pilot tools used (except for the FMS, which is 
always used), are not very specific and would require further investigation and 
dialog with pilots. 

8) Pilots have considerable latitude for making flight changes, particularly for altitude and 
speed changes, guided by the company Operations Control Manual. Request for route 
changes are more likely to require dispatcher approval. Sufficient pilot empowerment is in 
place at the surveyed operators to allow utilization of TASAR capabilities to seek 
improvements to the current flight plan. 

9) From a Dispatch perspective pertaining to time spent on flight optimization, there is a trade- 
off on time spent versus savings achieved; if airlines are not focused or motivated to spend 
additional time to improve the efficiency of flights, then they either do not have the means 
to do better (i.e., in the way of tools and available quality information), or it is not a big 
cost issue to be considered. It is unlikely that they are just not focused on seeking cost 
improvements due to lack of focus and is likely related tool availability. 

a. A follow-up question would be concerning which flights should Dispatch expend 
more effort on optimization - long haul and/or international flights? Also, once 
operators are able to operate in a more “free flight” airspace perhaps in NextGen, 
with fewer constraints imposed (versus the more rigid route structures of today’s 
operations), then more significant gains can be made, and greater focus on 
optimization by Dispatch may be warranted. 
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10) Dispatcher can inquire position reports from the FMC and derive additional real-time 
information on current flight parameters, which is viewed as a very effective re-dispatch 
and re-evaluation tool. 

a. From survey responses, Dispatch tends to play a relatively limited role for in-flight 
re-planning. This is particularly the case for the Global Network Carrier surveyed, 
which only provides support services while the aircraft is in-flight when prompted 
by pilot requests. 

b. A potential area of research is to determine to what extent should Dispatch focus 
on in-flight re-planning, which is currently not their focus, or should this be 
delegated to flight-deck tools, e.g., TASAR. What is the proper balance of Dispatch 
versus aircraft-based in-flight re-planning to ensure synergy? In addition, to what 
extent can TASAR take on flight planning typically done by dispateh, particularly 
in future NextGen operations that support “free flighf ’ capabilities? 

1 1) TASAR, with good (i.e., pertinent, accurate, and timely) information on ATC metering and 
flow management and weather information (especially en route and at the destination 
airport), has the potential to provide significant tactical re-planning capabilities for 
operational efficiency. With TASAR, the key issue is its usability, i.e., providing benefits 
while at the same time being streamlined with operator dispatch, own ship flight procedures 
using the FMS, and with ATC’s overall air traffic control paradigm (change request 
clearances, traffic flow management, arrival management, etc.). 

12) A number of improvement opportunities are identified as a result of survey responses. It 
would be beneficial to more closely evaluate the major aspects of flight planning and re- 
planning processes and how they translate into successful conduct of the flight. Further 
analysis on which information elements and how improvements in information quality will 
provide improved flight planning and in-flight re-planning is warranted. 

13) Additionally, the roles of Dispateh in planning and in-flight re-planning, in conjunction 
with the role of the flight deck (applications and flight crew capabilities) in performing in- 
flight re-planning using tools such as TASAR should be clearly delineated and allocated 
synergistically for maximum benefit. In addition, re-planning in the presence of changing 
environmental factors needs to be aecomplished in a consistent way with current and future 
ATC processes and procedures. 

In summary from an aircraft equipage perspective, TASAR is poised to be readily achieved, with 
the possible exception of ADS-B IN. A positive cost benefit business case is a key requirement for 
operators to continue to equip and enhance their avionics, EFB and data communications level of 
equipage for their aircraft fleets. Perhaps the most significant challenge is the development of a 
more robust cost benefit assessment for TASAR that supports synergistic usability with Dispatch 
and ATC processes as part of the in-flight re-planning to achieve operational efficiencies in the 
presence of changing environmental conditions (e.g., weather and airspace disruptions). 

Note: While survey results were carefully reviewed, survey questions and corresponding 
responses are at times qualitative and subjective in nature. In addition some responses 
represent only a small sample and thus cannot be used to make fundamental conclusions 
and extrapolations. However, the three operators represented in the survey and the 
comprehensive questions and responses from the various stakeholders involved in flight 
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planning and flight execution do allow reasonable conclusions to be drawn that were used 
to inform the TASAR research team in developing updates to the TASAR application. 

4.2 Certification and Operational Approval Requirements 

This section examines the certification and operational approval requirements for TASAR. The 
analysis begins with a comprehensive operational hazards analysis and defines and documents 
safety requirements that serve as mitigations to potential operational hazards (Section 4.2.1). 

Section 4.2.2 determines TASAR requirements for adherence to industry standards for aircraft 
systems development and EFB devices. Specific design, development, test, validation, and 
approval requirements needed for entering TASAR into operational service are also documented 
in this section. 

Section 4.2.3 provides an analysis of TASAR with respect to FAA guidelines and regulatory 
requirements for certification and operational approval and determines the most appropriate and 
efficient methods and processes for pursuing certification and operational approval. A 
corresponding detailed plan for approval is provided. 

TASAR artifacts for certification and operational approval processes were identified and 
underwent a “dry run” review with DERs at Rockwell Collins for feedback to determine if any 
changes to the artifacts and the approval processes were deemed necessary. These are documented 
in Section 4.2.4. 

The TAP HMI has undergone redesign by NASA to incorporate pilot feedback based on HITE 
simulation experiments and from actual flight trials. Section 4.2.5 documents the results of an 
analysis of NASA’s TAP HMI Version 4 to assess certification and operational approval 
requirements. Specific focus of this analysis is on the TAP HMI V4 graphical elements depicting 
aircraft navigation information (e.g., routes, heading), traffic information, weather and airspace 
information, and wind information. The analysis provides observations with respect to regulatory 
reference on specific HMI changes to reduce the threshold for certification and operational 
approval. 

4.2.1 TASAR Operational Hazard and Safety Requirements Analysis 

This section provides the results of safety analyses performed to identify Operational Hazards and 
Safety Requirements for TASAR as an application that can be hosted on a PED / Portable EFB. 
Two safety assessment methodologies were used that are compliant with the FAA’s Safety 
Management System (SMS): 

Method 1 A traditional safety assessment identification of hazards for the intended function 
of the system being developed, determination of worst credible effect due to the 
hazard, and subsequent EEC using ARP 4761 [9], AC 23-1309 [10] and AC 25- 
1309 [11] for Part 23 and Part 25 aircraft operations 

Method 2 RTCA DO-264 / EUROCAE ED 178 A Operational Safety Analysis [12]. 

The full report of the Operational Hazard and Safety Requirements Analysis is found as a NASA 
Contractor Report [7]. 
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4.2.1.1 


Approach to Safety Assessment 

Two safety assessment approaches were used to determine the FEC for TASAR. FECs are based 
on Operational Hazards and available mitigations that were identified using these two methods. 
As presented below, the two safety analyses conclude that the worst case FEC for TASAR will 
likely be of “No Effect” and no higher than “Minor Effect.” This determination is subject to 
evaluation and approval by cognizant FAA certification and operational approval organizations 
responsible for authorization of EFB applications. Supporting rationale for the “No Effect” 
designation is provided in the safety analyses in 4. 2. 1.4 and 4.2. 1.5 below. 

Note: NASA and Rockwell Collins met with FAA certification (AIR) and operational approval 
(AFS) authorities and presented the approval requirements described in this report to them. 
They indicated that TASAR would warrant a “Minor Effect” FEC due to workload 
considerations, but noted that from an operational failure perspective, the “No Effect” 
designation is justified. Section 4.3 discusses the results of the meeting with FAA. 

4.2. 1.2 Safety Assessment Methodology High-Level Description 

4.2. 1.2.1 Method 1 Safety Assessment Overview 

Method 1 (i.e., based on the analyses indicated by ARP-4761, AC 25-1309, AC 23-1309) 
represents the traditional system safety process for airborne systems and equipment, e.g., TASAR. 
This method performs the following steps relative to the intended function of the new system 
capability: 

1 ) Evaluate the intended function per phase of flight 

2) Identify failure events, e.g., loss of function; undetected, erroneous trajectory change 
request(s), etc. 

3) Examine the effect of the these failures on aircraft, pilot (or flight crew), and ATC 

4) Determine the Hazard Classification, e.g.. Major, Minor, No Effect 

5) Determine frequency of occurrence, e.g., per flight hour, per operation 

6) Provide rationale for hazard assessment. 

4.2. 1.2. 2 Method 2 Safety Assessment Overview 

Method 2 (i.e., based on RTCA DO-164 / ED-78A) represents a system-of-systems analysis 
approach that is well-suited for allocating safety requirements across a multiple-system function. 
This allows a more balanced allocation of safety requirements across systems and sub-systems, 
which is particularly beneficial for higher criticality systems. While an excellent approach for 
systems analysis, it is not as well suited for lower criticality systems such as TASAR. This is 
particularly true in the realm of “Minor” criticality systems, where this approach puts excessive 
emphasis on formal analysis related to operational effects such as workload (pilots and air traffic 
controllers), which are often highly subjective and difficult to assess in a quantitative manner. 

Method 2 follows the following evaluation steps: 

1) Perform an Operational Hazard Assessment (OH A) 

a. Identify Operational Hazards 

b. Determine the worst credible outcome of the Operational Hazard, i.e., the 
Operational Effect, e.g., collision, loss of separation, workload, etc. 
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c. Determine the Severity Classes for each Operational Effect, e.g., Catastrophic, 
Major, Minor, etc., and identify the maximum allowable probability of occurrence 
of the Operational Effect 

d. Determine the Effects Probabilities , which represent the probabilities of available 
mitigation(s) to the system to help reduce the probability of occurrence of the 
Operational Effect due to the Operational Hazard 

e. Assign Safety Objectives, which represent the probability of occurrence of each 
Operational Hazard that is allowable for ensuring the safety of the application 

f Identify External Mitigation Means, i.e., barriers external to the application that 
reduce the adverse effects and impact to safety when Operational Hazards occur. 

2) Allocate Safety Objectives and Safety Requirements 

a. Identify Abnormal Events and Basic Causes internal to the applications that could 
lead to the occurrence of each Operational Hazard 

b. Identify Internal Mitigation Means, i.e., barriers internal to the application that 
reduce the probability of the Operational Hazard from occurring in order to achieve 
the required Safety Objective 

c. Allocate Safety Requirements to the sub-functions comprising the application. 


4.2.1.3 Trajectory Change Requests - Today's Operations 

This section briefly describes the trajectory change request process in today’s operations between 
the pilot and ATC for making change requests to the current flight plan. As conditions change 
during flight, it is common for the pilot to request an amendment to the ATC-cleared trajectory, 
e.g., to meet some need for safety, efficiency, or ride quality / comfort for passengers. 

In today’s operations, pilot requests are often made with little or no awareness of the traffic 
situation or ATC sector considerations. Some of these change requests are denied by ATC for the 
following reasons: 

1) Change request conflicts with other traffic 

2) Change request conflicts with sector procedures in use by ATC 

3) Change request is requested too close to the next sector handoff 
The effects of denial of a change request by ATC to the pilot are: 

1) Unnecessary workload burden on ATC 

2) Discourages the pilot from making future requests to improve their flight 

3) Elight improvement opportunities are often unrealized because pilot may not be aware of 
requests that would improve efficiency and be ATC approvable. 


In general, the pilot seeking opportunities of improved safety, efficiency or ride quality has rather 
limited awareness of many of the factors that would adversely affect ATC acceptability of change 
requests to the current flight plan. This environment is not conducive for the pilot to seek 
operational efficiency improvements due to lack of situational awareness of the external 
environment that may constrain changes to the flight plan. 
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The next section explores a new TASAR capability that serves as an advisory-only tool to the pilot, 
providing informed trajectory change request candidates for pilot consideration as possible change 
requests to ATC for operational benefit. 

4.2.1.4 TASAR "Intended Function " Description 

TASAR is a flight deck-based decision aid consisting of software automation algorithms and a 
primarily textual display and is intended as an advisory-only service to the pilot to seek trajectory 
improvement opportunities over the current flight plan. TASAR is expected to be a hosted software 
application on an EFB. A Class 2 EFB installation is anticipated, with TASAR becoming a future 
Type B software application, pending successful certification and operational approvals by FAA. 
The TASAR EFB will interface to avionics as read-only (i.e., it will not transmit to avionics) as 
defined in the current concept of operations. 

Note; A comprehensive assessment of FAA EFB regulations and guidance on FED / Portable 
EFB-based flight deck application was made under this contract and is presented in sub- 
sections of Section 4.2 below. Feedback from FAA approval authorities on the TASAR 
application is also provided below in Section 4.3 and in Appendix E of this report. 

Based on inputs provided by 1) the pilot (in the form of flight objectives and optimization criteria), 
2) on-board avionics systems, and 3) airborne internet data connectivity, the TASAR application 
computes available trajectory change request candidates that may improve the current flight plan. 
Trajectory change request candidates provided by TASAR are intended to have relatively high 
probability of ATC approval if requested by the pilot, as TASAR seeks to provide flight- 
optimizing, traffic-avoiding recommended trajectory candidates that anticipate ATC and airspace 
constraints. 

The pilot has full discretion on the use of TASAR-provided trajectory change request information; 
they can choose to use TASAR-recommended trajectory change request candidates as part of a 
change request to ATC, or they can choose to ignore them. TASAR can be manually inhibited at 
any time, for any reason. Thus, in the event of observed spurious behavior of TASAR due to any 
system failure, inaccurate data obtained via network enabled information sources, or TASAR 
being a source of distraction to the flight crew, the pilot can simply inhibit or ignore TASAR. By 
following their training, the pilot can manage the use of TASAR in such away so that TASAR will 
not result in any workload increase in the flight deck. 

TASAR is a supplemental system intended to provide operational benefits, without adversely 
impacting safe operations, and it does not replace any aircraft system or procedure needed for 
flight operations. The TASAR display is passive without explicit display of traffic and own ship 
position nor audible alerting. Foss of the TASAR EFB application for any reason does not affect 
the Minimum Equipment Fist (MEF) and does not affect normal flight operations. 

TASAR information sources may include the following: 

1) Own ship systems (aircraft state, auto-flight settings, flight plan and performance 
information from FMS, etc.) 

2) Traffic data via ADS-B IN, Traffic Information Services Broadcast (TIS-B), or other 
sources via airborne internet 

3) Airspace system status and forecast (sector use and configuration. Traffic Management 
Initiatives, Special Use Airspace (SUA), etc.) 
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4) Weather status / forecast 

5) Wind status / forecast 

6) Operator flight planning, preferences, and objectives. 

4.2.1. 5 Method 1 Safety Analysis - Conventional Method 

This section addresses the safety assessment of TASAR using the traditional system safety process 
based on ARP 4761 [9], AC 23-1309 [10], and AC 25-1309 [11]. The key outcome of this safety 
assessment process is the determination of the FEC of the TASAR application. The EEC then 
drives the development and validation requirements and processes to be followed in integrating 
TASAR into the flight deck to gain certification and operational approval. 

Using this safety assessment process (i.e.. Method 1), applicants and certification and operational 
authorities (i.e., FAA aircraft certification and flight standards organizations) follow the process 
of assessing the new application and attendant procedures for potential failure modes and their 
impact on safety. 

4.2. 1.5.1 Key Factors that Influence the FEC of TASAR 

The following list represents key factors that influence the determination of the FEC for TASAR: 

1) TASAR is a supplemental system and thus is not relied on by critical functions supporting 
flight deck operations 

2) TASAR use is optional, i.e., not a required system for flight operations. In the event of 
failures of the TASAR system, TASAR can be ignored or disabled without adversely 
affecting operations 

3) TASAR has no MEE requirement 

4) TASAR can be manually inhibited at any time, for any reason 

a. Detected failure of the TASAR application 

b. Detected failure of the host EEB 

c. Spurious or inconsistent performance of recommended trajectory change requests 

d. Distracting effects of TASAR to the pilot 

5) Presence or loss of TASAR does not change responsibilities of the pilot for flight 
operations 

6) TASAR is an “advisory-only” system (i.e., does not provide guidance information) 

a. Pilot is not reliant on TASAR outputs to any extent to perform flight operations 

b. Pilot can choose to either utilize or ignore trajectory change candidate 
recommendations from TASAR as part of change requests to ATC 

7) Change request procedures are unchanged. 

a. Pilot must direct all change requests to ATC using conventional means 

b. ATC is responsible for reviewing request for acceptability, including separation 
from traffic 

c. ATC either 1) approves request and issues clearance, 2) provides an amended 
clearance, 3) defers request to next controller, or 4) denied request 

8) Undetected, misleading information associated with TASAR recommendations will have 
“No Effecf’ on the pilot, aircraft, and/or on ATC. Whether due to failure of one of the 

17 


TASAR sub-systems and associated automation processing, or being the result of 
inaccurate data obtained from ground-based or flight deck systems, spurious change 
requests are mitigated by flight crew inspection of the recommended trajectory change and 
by mitigation associated with the existing change request process. 

4. 2. 1.5. 2 Failure Effects Classification (FEC) 

Figure 1 (from [11]) provides a mapping of the “Effects” due to failures and the allowable 
“Probability of Occurrence” that lead to the determination of the FEC of the planned application 
(i.e., TASAR). Based on the above noted factors alone, this safety analysis (Method 1) comes to 
the conclusion that TASAR can be safely developed and implemented with a “No Effect” 
designation. Potentially, in the worst case, TASAR could rise to a “Minor Effect” designation in 
event of inconsistent candidate trajectory change request recommendation(s), which could result 
in workload issues (for the pilot and / or ATC). However, workload issues are not anticipated to 
be an issue for the pilot’s use of TASAR, as the pilot can simply ignore TASAR for any reason. 
Through proper training in the use of TASAR, the pilot should not allow to be distracted or be 
adversely influenced in using TASAR while conducting flight operations. From an ATC 
perspective, controllers will continue to conduct the trajectory change request process as in today’s 
operation and are not expected to experience a workload issue due to TASAR. 

Note: Based on our Technical Interchange Meeting with FAA approval authorities, FAA noted 
that TASAR would be viewed as a “Minor Effect” EFB application due to pilot workload 
considerations. Refer to Section 4.3 and Appendix E for results of our meeting with FAA 
approval authorities on the TASAR EFB application. 
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Figure 1 Acceptable Risk versus Potential Effects (Defined for Civil Aviation) 
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4.2. 1.5. 3 TASAR Application internal Mitigation Means 

The TASAR application itself provides additional inherent capabilities that further reduce the 
possibility of unintended adverse effects and are expected to enhance the usability of the 
application. These further serve to strengthen and support the “No Effects” EEC for TASAR: 

1) In order to prevent lengthy, complex trajectory change requests from the pilot to ATC, 
TASAR utilizes standard navigation databases and places limits on excessive waypoints 
included in the recommended change requests it provides 

2) TASAR displays flight path change opportunities using standard phrasing to facilitate 
voice communications 

3) TASAR may include capabilities to assess sector complexity and own ship’s proximity 
to the sector boundary in order to only recommend change requests that have a high 
likelihood of being approved by ATC. 

4.2. 1.5.4 Procedural Mitigations Available to the Pilot 

1) An additional characteristic of TASAR is that there is no “recovery” time required for the 
flight crew associated with its use. In other words, in using TASAR, the pilot remains on 
an ATC-cleared trajectory at all times. In the event of a TASAR system fault, the pilot need 
only remain on the current clearance while disregarding the TASAR display. A simple 
reset of TASAR, or by simply choosing to ignore TASAR inputs (e.g., by not looking at 
the TASAR display) allows the pilot to continue to focus on primary tasks in conducting 
flight operations (whether during normal operations or in the event of abnormal or 
emergency situations) 

2) The pilot has responsibility to evaluate TASAR-provided trajectory change candidates 
before making a change request to ATC, providing cross-check opportunities to detect 
spurious or false trajectory change candidates being offered by TASAR 

3) Aircraft systems, e.g., EMS, weather radar, serve as available, higher integrity information 
allowing quick check on acceptability and performance impacts of TASAR recommended 
trajectory change requests 

4.2. 1.5. 5 TASAR Phase of Flight Considerations 

1) Prom a phase of flight perspective, TASAR is intended for use primarily during en-route 
operations 

a. Trajectory change request candidates are offered by TASAR during the later 
portion of climb, while en-route, and to a lesser extent, into the early portion of 
descent operations 

b. TASAR is thus used primarily during non-critical phases of flight, i.e., above 
10,000 ft. 

4.2. 1.5. 6 TASAR Information Source Quality 

1) Due to the “No Effect / Minor Effect” PEC anticipated for TASAR, TASAR information 
source quality and integrity must be commensurate to support this PEC. 

a. TASAR input information quality and integrity requirements are driven not by 
safety considerations but by operational use considerations. 
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b. Low quality and/or misleading information can result in poor recommendations to 
the pilot for candidate trajectory change requests. The net effect is that TASAR will 
not be as effective in achieving envisioned operational benefits (e.g., time or fuel 
served). 

4. 2. 1.5. 7 TASAR Undetected Failure - Worst Case Effect 

1) From a TASAR Undetected Failure perspective, inefficient routing is the only adverse 
outcome. Existing mitigation of any safety hazards is provided by ATC, as already is done 
for trajectory change requests today. 

Note: The Safety Analysis using Method 2 (based on the Operational Safety Assessment {OSA} 
of DO-264 / ED-78 A) described in the next section takes a closer look at specific failure 
modes of TASAR. 


4.2.1.6 Method 2 Safety Analysis - Operational Safety Assessment Process 

This section provides the safety analysis of TASAR using the Operational Safety Assessment 
(OSA) process from RTCA DO-264 / EUROCAE ED-78A [12], referred to as Method 2 in this 
report. Figure 2 illustrates the process at a high-level using the ‘bow-tie’ model. 
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Figure 2 Operational Safety Assessment Process - Method 2. 


In Figure 2, the system of interest, in this case the TASAR application, is represented in the left- 
hand side of the “bow-tie”. The external environment in which the application operates, including 
environmental conditions (e.g., airspace influences, weather, traffic) and the external systems that 
are part of the overall operational concept (e.g., aircraft systems and ATC systems), are represented 
by the right-hand side of the “bow-tie.” 

The OSA process consists of the following major sub-processes: 1) the Operational Hazard 
Assessment (OHA), and 2) Allocation of Safety Objectives and {Safety} Requirements (ASOR). 
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In performing the OHA, the first step is to use operational experts from all stakeholder 
communities to identify potential Operational Hazards that may result from the application (e.g., 
TASAR). For each identified Operational Hazard, the next step is to determine the worst “credible” 
outcome, also referred to as the Operational Effect (OE). Examples are collision, loss of separation 
(major loss versus minor loss), workload, etc. 

For each Operational Hazard and associated Operational Effect, the Severity Class is determined. 
Severity Classes include catastrophic, severe major, major, minor, and no effect. For each 
Operational Effect and associated Severity Class, a “Probability of Occurrence” not to be exceeded 
to assure safety of operations are established, ranging from 10'^, 10'^, 10'^, 10'^, etc. for occurrence 
of the Operational Effect. The Operational Effects and Severity Classes are noted in Figure 2 on 
the right side of the bow-tie. 

Figure 3 provides a mapping of hazards to “the associated effects on operations due to each hazard 
class. The likely regions of applicability for the TASAR OSA process described in this section are 
highlighted in Figure 3. The highlighted regions represent “Minor” and “No Effects” FECs. 
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Figure 3 ED78A/D0264 Based Hazard Classification Matrix 

From the OHA sub-process, each Operational Hazard is assigned a Safety Objective that it must 
meet in order to assure safe operations. It is the task of the ASOR to ensure that the Safety 
Objective is met. It is noted that for each Operational Hazard, there could be multiple Operational 
Effects, thus resulting in multiple Safety Objectives being assigned to each Operational Hazard. 
The ASOR must assure that all Safety Objectives are met for each Operational Hazard. 

In order to mitigate the effects of the Abnormal Events and Basic Causes identified as root causes 
of failures, it will be necessary to identify relevant mitigations internal to the application, denoted 
as Internal Mitigation Means. These mitigate the effects of Abnormal Events and Basic Causes to 
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achieve the Safety Objectives for eaeh Operational Hazard. This then also allows specifying Safety 
Requirements that are associated with sub-system elements internal to the application. The 
combination of Abnormal Events, Basic Causes, Internal Mitigation Means, Safety Objectives and 
Safety Requirements are illustrated by the left-side of the bow-tie. 

The OSA proeess in [12] is beginning to be widely used by EUROCONTROL and EAA in the 
development of Safety, Performance, and Interoperability Requirements for ADS-B IN 
applieations. This process is well suited for higher criticality system-of-systems and allows a more 
formal analysis process using fault trees and event trees. Eault Trees are typically used to capture 
the left-hand side “bow-tie” process of the ASOR, while Event Trees are typically used to represent 
the OHA process eharaeterizing the external environmental factors represented by the right-hand 
side of the bow-tie. 

Note: While the strength of the OSA process is that it is able to analyze complex, high-eriticality 
system-of-systems and allows for a relatively balaneed approaeh for alloeating integrity 
requirements across all systems, the process may not be as well suited for lower-eriticality systems, 
e.g., TASAR, as the fault tree and event tree methodologies and assoeiated caleulations begin to 
become onerous in terms of their ability to analyze the more qualitative and subjective aspeets of 
these types of applications. It is also often quite difficult to quantitatively prove probabilities 
assoeiated with workload faetors and performanee of the human to perform various functions. This 
often times becomes a significant and time consuming (and costly) issue in gaining approval for 
the safety requirements that result from using the methodology. 

Note: Considerable consideration has been given in this report to the identification of Operational 
Hazards potentially associated with TASAR. However, the report intentionally stops short of 
performing a quantitative analysis of the Safety Objectives and the probabilities of the barriers 
provided by the mitigations identified, since TASAR was determined to have a “No Effeet” or in 
worst case a “Minor” EEC. The OSA presented is thus an abbreviated OSA relative to [12]. 

4.2. 1.6.1 Operational Hazards Identification 

Before eommeneing with the identification of Operational Hazards using the Method 2 OSA 
approach in this section, it is noted that the same high-level factors and mitigation already 
deseribed in 4.2. 1.4 (Method 1) also apply here. The next step takes a eloser look at Operational 
Hazards that could occur using the TASAR application. 

As noted earlier. Operational Hazards result from Abnormal Events and Basie Causes , whieh 
represent errors and failures in actions associated with the human operator (e.g., the pilot), or 
systems functions (e.g., TASAR automation). Abnormal Events include both errors by the pilot in 
relation to TASAR use and in interactions with ATC as part of the ehange request proeedure. 

To more closely examine potential sources of errors associated with actions by humans and 
TASAR automation processing, Eigure 4 illustrates potential information flows within the NASA 
TASAR applieation, TAP. 

Erom Eigure 4, the following information exchanges associated with human and automation 
proeessing notions represent potential souroes for errors and misleading information that may 
result in Operational Hazards: 
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Figure 4 TASAR Functional Diagram* 

*Note: The information elements identified in Figure 4 are notional at this point and are being 

refined as part of the detailed design of TASAR. 

4. 2. 1.6. 2 Human Actions Potentially Leading to Abnormal Events 

The following list identifies human actions that provide the opportunity for occurrence of 

Abnormal Events (i.e., when human actions are performed in error): 

1 . Pilot, flight crew 

a. Enters TASAR configuration, objectives, and optimization criteria via the TASAR 
HMI 

b. Receives and interprets TASAR data via the TASAR HMI 

i. e.g., recommended trajectories, conflict status, fuel reserve status, etc. 

c. Communicates change requests to ATC 

2. Air Traffic Controller (en-route) 

a. Provides separation assurance services 

b. Communicates change request clearances to pilots 

Note: As the detailed design for TASAR is being developed, there is a concern that some route 
and constraint data may not be readily accessible from onboard systems and that it may be 
necessary that some of this data be manually entered by the pilot. This raises the potential 
of increased pilot workload that may become a concern for usability of the TASAR 
applications and could factor into the OSA as a workload issue; it may also increase the 
possibility of false data entry by the pilot. 
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4.2. 1.6. 3 TASAR Automation Processing Actions Potentially Leading to Basic Causes 

The following actions performed by TASAR (i.e., decision support algorithms) provide 
opportunity for occurrence of Basic Causes (i.e., when actions by automation are erroneous); 

• TASAR-related processing that could result in undetected misleading information. 

Any misleading information provided by information sources to TASAR, or errors and failures in 
TASAR automation processing, could potentially result in misleading trajectory change request 
candidates being recommended to the pilot for consideration. Such misleading information may 
detract from the usability of TASAR to achieve operational benefits. However, since the flight 
crew has no authority to deviate from their ATC clearance, regardless of the information provided 
by TASAR, any occurrence of misleading information from TASAR will be non-hazardous in 
nature and is completely mitigated by the ATC clearance procedure. 

Detailed assessment of Abnormal Events and Basic Causes associated with TASAR are discussed 
in [7]. 

Detailed List of Potential TASAR Operational Hazards 

Table 5 provides a list of the Operational Hazards identified using the OSA process described in 
this section. Associated mitigations, internal or external to TASAR, are also identified. 


Table 5 TASAR Operational Hazards and Mitigations 


Operational Hazard 

Description 

Mitigation 

OH - 1: TASAR could provide one or more 
change request candidates that are not 
conflict free 

This Operational Hazard is the result of poor 
information quality and/or mixed ADS-B Out equipage 
environment, where not all traffic is known 

ATC provides separation assurance 
independent of TASAR 

OH - 2: Pilot could misinterpret TASAR 
candidate change request and could 
unknowingly request a trajectory 
clearance that is not conflict free or could 
lead toward hazardous airspace 

TASAR could "inadvertently" mislead or confuse the 
pilot who could then misrepresent the TASAR change 
request to ATC 

ATC provides separation assurance 
independent of TASAR 

Aircraft safety systems (e.g.. Traffic Alert and 
Collision Avoidance System, weather radar. 
Terrain Awareness and Warning System) 
provide hazard detection and alerting 

OH -3: Pilot could follow the wrong 
trajectory clearance following receipt of 
amended clearance from ATC 

Pilot could request a change recommended by the 
TASAR system, and although ATC amends the request, 
TASAR-induced confusion could lead the pilot to follow 
the request instead of the clearance 

ATC monitors execution and intercedes 
(same as today) 

Pilot training 

Pilot crosschecks clearance with FMS 

OH - 4: ATC, somehow being aware of 
TASAR capability for the aircraft / pilot 
requesting a change request to the flight 
plan, could be less vigilant to provide 
separation assurance 

The concern is whether ATC could become complacent 
over time, when receiving TASAR requests 
(note that TASAR equipage is not specified on filed 
flight plans or included in pilot-request verbiage) 

Existing ATC procedure to check all requests 
for separation 

Note: This is not a credible Operational 
Hazard because separation assurance is 
ATC's primary responsibility 

OH - 5: TASAR could provide numerous 
spurious and/or inconsistent series of 
change request candidates leading to 
multiple requests 

If change request recommendations are not reinforced 
from one request to the next, multiple counteracting 
requests could be issued 

These requests could become a nuisance issue and 
potentially could lead to a workload issue for ATC 

ATC denies user requests if workload is too 
high 

OH - 6: TASAR could recommends a 
trajectory candidate with miscomputation 
of fuel burn 

Pilot reliance on TASAR fuel burn estimates (presented 
to help pilots choose between multiple request 
options) could lead to greater fuel burn than expected 

Pilot crosscheck of FMS prediction of fuel 
burn 
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Operational Hazard 

Description 

Mitigation 

OH -7: Unexpected weather could 
develop on TASAR recommended route 
after ATC approval 

Unexpected weather could require additional change 
requests and therefore more fuel to be used 

Normal procedures for responding to 
unexpected weather 


Reviewing the above Operational Hazards, it is noted that due to the very strong and significant 
mitigations already provided by ATC separation assurance and pilot procedures in today’s very 
safe operations, the worst case safety effect could potentially be workload for pilot and/or 
controllers. Since TASAR is an advisory-only system and can be manually inhibited by the pilot 
at any time, for any reason, the most likely FEC for TASAR would be “No Effect”. With the “No 
Effect” or perhaps “Minor Effect” EEC, TASAR is amenable for integration as an EEB application. 

Note: Based on our Technical Interchange Meeting with EAA approval authorities, EAA noted 
that TASAR would be viewed as a “Minor Effect” EEB application due to pilot workload 
considerations. Refer to Section 4.3 and Appendix E for results of our meeting with EAA 
approval authorities on the TASAR EEB application. 

The safety analysis in this section strongly indicates that the TASAR EEB application at most 
warrants a “Minor Effect” FEC. The following subsections of Section 4.2 address EEB standards 
adherence requirements (Section 4.2.2), analyze TASAR with respect to EAA guidelines and 
regulatory requirements for certification and operational approval (Section 4.2.3), and develop 
representative TASAR artifacts for certification and operational approval processes (Section 
4.2.4). 

4.2.2 TASAR Requirements for Adherence to Industry Standards 

This section documents the results of an analysis conducted to identify EEB standards adherence 
requirements for TASAR. While not yet directly providing the certification and operational 
approval artifacts for TASAR certification (discussed in Section 4.2.3), this section identifies the 
steps toward such approvals and makes observations as they apply to the TASAR application. This 
section focuses primarily on EEB hardware and software requirements, including installation 
considerations. 

Note: The TASAR Operational Hazard and Safety Requirements Analysis in Section 4.2.1 above 
has aheady determined that TASAR will at most have a “Minor Effect” EEC which was 
confirmed in our meeting with EAA approval authorities (Section 4.3). 

4.2. 2.1 Applicable FAA Regulatory and Guidance Documents 

This section summarizes key documents that are applicable as FAA regulatory or guidance 
documents for certification and operational approval of EFBs and their attendant applications. The 
following is among the list of documents reviewed or considered in assessing EFB standards 
adherence requirements for TASAR described herein: 

1. AC 120-76C, Guidelines for the Certification, Airworthiness, and Operational Approval 
of Electronic Flight Bag Computing Devices [13]. 

This document is intended for all operators conducting flight operations under Title 14 of 
the Code of Federal Regulations (14 CFR) part 121, 125, 135, or 91 subpart F (part 91F) 
and part 91 subpart K (part 9 IK). It is a key guidance document for EFB use with 
applicability to TASAR. 
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2. Flight Standards Information System (FSIMS) - 8900.1 Change 47, Vol. 4, Chapter 15 - 
EFB Operational Authorization Process [14], 

This document provides the FAA approval perspective, providing the Principal Operations 
Inspector (POI) checklists followed for EFB and associated applications approval, 
including approval considerations for TASAR. This is a key document that identihes the 
EFB authorization process and provides detailed guidance on the checklists that must be 
addressed with the POI. 

3. AC 91.21-1, Use of Portable Electronic Devices Aboard Aircraft [15]. 

This document addresses the use of PEDs, including their potential to hazardously affect 
aircraft communication and navigation equipment. It allows the use of non-transmitting 
PEDs during non-critical phases of flight (e.g., >10,000 ft., which is currently the intended 
use for TASAR). It is noted that it may be desirable to use TASAR in the later stages of 
climb, and early stages of descent, perhaps below 10,000 ft.; this should be allowable due 
to the low FEC expected for TASAR, pending EAA approval as TASAR undergoes 
certification and operational approval. Wireless connectivity for TASAR could be 
considered as a Transmit PED (T-PED) and may require the ability to demonstrate isolation 
of the T-PED from interfering with avionics (e.g., communications and navigation 
systems). 

4. AC 20-173, Installation of Electronic Flight Bag Components [16]. 

5. AC 21-16, RTCA Document DO- 160 “Environmental Conditions and Test Procedures for 
Airborne Equipment” [17]. This document pertains to Electro-Magnetic Interference 
(EMI) requirements for read-only data interfaces to avionics and High Intensity Radiative 
Eields (HIRF) requirements for transmit data interfaces to avionics. TASAR requires only 
read-only access to avionics and thus will need to meet EMI requirements (or delegate this 
requirement to an Aircraft Interface Device through which the TASAR EEB may interface 
to the avionics systems. In addition TASAR wireless connectivity likely requires additional 
isolation testing (i.e., TASAR as a T-PED) to ensure non-interference to avionics systems. 

6. TSO-C195 (i.e., RTCA DO-317 - ASAS MOPS), Avionics Supporting Automatic 
Dependent Surveillance - Broadcast (ADS-B) Aircraft Surveillance Applications (ASA) 
[18]. This document pertains to TASAR for ADS-B IN/OUT performance requirements, 
but not for traffic display purposes, which is not applicable for the TASAR HMI. 

7. SAE ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process 
on Civil Airborne Systems and Equipment [9]. Applicable for TASAR Safety Assessment 
of Operational Hazards. 

8. AC 23.1309-1, System Safety Analysis and Assessment for Part 23 Airplanes [10]. 
Applicable for TASAR Safety Assessment of Operational Hazards. 

9. AC 25.1309-1, System Design and Analysis [11]. Applicable to TASAR system design. 

10. SAE ARP 4754A, Guidelines for Development of Civil Aircraft and Systems [19]. 
Applicable to TASAR system design. 

1 1 . AC 20-115, RTCA, Inc., Document RTCA/DO-1 78B [20]. This is not applicable to TASAR, 
as TASAR is expected to be at most a “Minor” failure effect classifcation. This document 
is primarily for Type C applications, e.g., applications that require depiction of own ship 
position and/or are of “Major” or higher FEC. 
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12. AC 20-152, RTCA, Inc., Document RTCA/DO-254, Design Assurance Guidance for 
Airborne Electronic Hardware [21], This is not required for “Minor” FECs, as a Class 2 
EFB EEC suffices; not applicable to TASAR. 

13. AC 20-159, Obtaining Design and Production Approval for Airport Moving Map [22]. 
This document pertains to the display of own ship position, e.g., display and airport surface 
situational awareness applications hosted in EFBs. This is not applicable to TASAR per 
current concept of operations and HMl design. 

14. AC 25-1 1 A, Electronic Elight Deck Displays [23]. Applies to Class 3 EFBs, i.e., installed 
as part of flight deck and is not applicable for TASAR. 

15. AC 91-78, Use of Class 1 or Class 2 Electronic Elight Bag (EEB) [24]. This is not 
applicable to TASAR, as it relates to Type A applications that apply to replacement of 
paper and other documentation. 

16. TSO-C165, Electronic Map Display Equipment for Graphical Depiction of Aircraft 
Position [25]. Not applicable (NA) to TASAR as it related to display of own ship position; 
not part of TASAR concept of operations and FlMl design. 

17. RTCA/DO-257A, Minimum Operation Performance Standards for the Depiction of 
Navigational Information on Electronic Maps [26]. Not applicable to TASAR; not part of 
TASAR concept of operations and HMl design. 

4.2.2.2 Summary of EFB Standards Adherence Requirements 

In establishing EFB standards adherence requirements, the EFB application’s intended function 
and associated FEC directly impact certification and approval requirements. The TASAR intended 
function was examined earlier in Section 4.2. 1.3; TASAR is an optional, advisory-only decision 
support tool to recommend trajectory change improvement opportunities to the pilot / flight crew. 
As such, TASAR is supplemental equipment, does not replace any required avionics functions, 
and is not needed as part of the MEL for flight operations. Use of TASAR is at the discretion of 
the pilot, i.e., the pilot may choose to ignore TASAR or can manually inhibit its operation at any 
time for any reason. 

Analysis of TASAR operational hazards and safety requirements suggests that TASAR at most 
warrants a “Minor Effect” FEC, and may in fact be of “No Effect” in terms of safety impact. This 
makes TASAR amenable as an EFB application (refer to Section 4.2.1 and [7]). 

Note; Section 4.3 confirms the “Minor Effect” FEC designation based on feedback from FAA 
approval authorities (Section 4.3). 

While TASAR, as a new EFB application, does not map directly into already defined Type A or 
Type B applications, it has many of the characteristics of a Type B application. Thus TASAR is 
well aligned with Type B applications; yet it is somewhat less stringent than typical Type B 
applications in terms of FEC per its intended function. TASAR is viewed to be of Type B. 

Note: FAA approval authorities indicated that although not explicitly identified as a Type B 
application in AC 120-76, they consider TASAR to be of Type B (refer to Section 4.3). 

In addition, TASAR is expected to be implemented as a Class 2 FED / Portable EFB. The Class 2 
EFB requirement is due to the read-only interface needed by TASAR to on-board avionics systems 
and data link connectivity via installed antennas for accessible information sources, e.g., weather 
information. 
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As a Class 2 EFB, a mounting device is required for TASAR with the following attendant 
requirements (for the installed mounting device); 

1) must have operational suitability in ail ground and flight operations and conditions 

2) must not interfere with flight crew duties 

3) must be easily stowed when not in use 

4) must not obstruct primary or secondary fields of view, and 

5) must not obstruct egress. 

As the TASAR EFB is portable (i.e., not installed permanently as part of the flight deck), it must 
be easily removable, without tools, by the pilot / flight crew member. The EFB must be accessible 
to the pilot / flight crew. A cockpit mount is recommended / selected for TASAR as compared to 
a yoke mount to facilitate operational approval and for a more cost effective installation. 

Because TASAR is primarily utilized during en-route operations, generally above 10,000 ft., it is 
primarily used during non-critical phases of flight. However, due to its relatively low EEC, i.e., 
low-criticality of the TASAR application, it is expected to also be useable during the later portion 
of climb and early portion of descent operations and is not expected to adversely affect these more 
critical flight phases. 

The EFB standards adherence requirements examined are expansive and detailed in nature. 
Appendix B documents these results; specifically the roles and responsibilities of the operator, 
manufacturer, installer, avionics vender, and also of FAA certification and operational approvers 
of newly developed EFB applications, such as TASAR. 

4.2. 2. 3 FAA Principal Operations Inspector (POl) Checklists 

The following represent the checklists that are used by the POI as part of the EFB approval process 
and are found in [14]. They are addressed later in more detail in Appendix D but are provided here 
for initial reference: 

• Figure 4-79 represents Checklist 1, ’’Tabletop Electronic Flight Bag Evaluation 

• Figure 4-80 represents Checklist 2, “Electronic Fight Bag Operational Evaluation” 

• Figure 4-81 represents the “Evaluation Report Information Template” 

• Figure 4-82 represents Checklist 4, “Electronic Flight Bag Line Evaluation Job Aid”. 

4.2.3 FAA Guidelines and Regulatory Requirements for TASAR Approval 

This section examines FAA guidelines and regulatory requirements needed for the certification 
and operational approval of the TASAR EFB flight-deck application. It provides a conceptual plan 
that identifies anticipated steps to be followed that are expected to lead to successful certification 
and operational approval of TASAR. This section and Appendix C lay out this path to achieving 
approval without going through the actual certification and operational approval process. This 
information is provided to support a future certification effort for TASAR. Specifically it offers a 
Certification Plan for TASAR. 

Note: In our meeting with FAA approval authorities (see Section 4.3), FAA did not see the need 
for a Project Specific Certification Plan (PSCP) for the TASAR software, just for the 
installation. If the applicant already has an existing EFB installation, then the operational 
approval process is for a user to go directly to their POI. 
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The results doeumented in this seetion also served as the basis for providing 1) representative 
artifacts for a DER review dry run, and 2) an analysis of DER feedback from this dry run, which 
are documented in Section 4.2.4 below. 

4.2.3.1 FAA Certification and Operational Approval Process - High-level View 

The FAA certification and operational approval of aircraft functions involves many disciplines 
in a highly interactive and coordinated manner in order to achieve product approvals that ensure 
their safe use in flight operations. This section provides a brief overview. 

Addition of new avionics functions or updates to existing functions typically involves issuance 
of one of the following: Type Certificate (TC), Amended Type Certificate (ATC), Supplemental 
Type Certificate (STC), Amended Supplemental Type Certificate (ASTC), Production 
Certification (PC) or other means. 

Key FAA organizations involved in this process of supporting and assessing the applicant’s data 
submittals for approval are the Aircraft Certification Office (ACO), Flight Standards Services 
(AFS), and the Aircraft Evaluation Groups (AEG). 

In order to achieve product approval requires multiple disciplines to be vetted and assured: 1) 
safety to demonstrate airworthiness, 2) manufacturing, 3) maintenance, 4) operations, etc. FAA 
ACO is responsible for assuring safety of new and updated avionics products and issues design 
approval via the approval process and guidelines for TC, STC, ATC, ASTC, PC, and other 
means. 

In addition to the safety assurance processes of proving the integrity of the product design, 
another key aspect of the approval process involves the manufacturing of the avionics product 
itself Manufacturing regulations and guidelines involve additional processes, including assuring 
that parts are manufactured according to Technical Standard Order (TSO), Parts Manufacturer 
Approval (PMA), or using Conformity inspections. FAA Manufacturing Inspection District 
Offices (MIDOs) are responsible for assuring the correctness and quality assurance of the 
manufacturing of avionics parts. 

Initial engagement with FAA on a new or revised product approval may include dialog regarding 
orientation of the approval process, gaining some initial guidance before launching the actual 
certification project with FAA, and receiving a familiarization briefing about the process. This 
is then followed by launching the Certification Plan. 

4.2. 3. 2 Purpose of Certification and Operations Approval Plan 

The goal of the Certification and Operations Approval Plan {from here on referred to as the Project 
Specific Certification Plan (PSCP)} is to establish a framework plan and schedule between the 
applicant and FAA on how the applicant intends to demonstrate compliance of the new or revised 
system capability to the Federal Aviation Regulations (FARs). 

A proper certification plan assures the FAA that the applicant has reviewed the FARs and is aware 
of the applicable requirements that need to be addressed as part of the approval process. The 
applicant receives FAA concurrence (or receives feedback on what updates will be needed to the 
PSCP in case not all elements are properly addressed) that the PSCP describes an acceptable means 
of demonstrating compliance with the FARs. 


29 


Note: There are multiple references made in FAA guidance documents concerning the 
Certification Plan, e.g., in FAA Order 81 10.4C [27]. 

1) CP (Certification Plan) - previously not required by FAA in earlier versions, but now 
required by FAA in this latest order 

2) CPP (Certification Project Plan) - represents FAA’s ACO’s high-level project plan 

3) PSCP (Project Specific Certification Plan) - represents the composite of both the 
applicants and FAA’s project plan information. The PSCP contains elements of the CP 
and CPP and includes relevant details of the Certification Process Improvement (CPI) 
initiative [28] between FAA and industry. 

The key element of the PSCP is the Compliance Check List, which indicates that the applicant 
understands all appropriate regulatory requirements to be satisfied for achieving certification and 
operational approval. The Compliance Check List provides a summary of the regulatory 
requirements via reference and points to the type of associated data submittals (i.e., artifacts) that 
need to be provided to approving authorities. 

The PSCP is important as part of the engagement process with FAA for product certification and 
approval. The PSCP ensures that the individual elements of the plan take place in proper order and 
at designated timeframes. This allows for planning of personnel and resources by both the 
applicant and FAA and provides a roadmap for coordination, information exchanges, and 
milestone completion dates. Without a well-coordinated PSCP and associated schedule 
information, the certification project stands little chance for timely completion. 

Typically, preparation of the PSCP should begin as soon as the basic design has been determined 
in order to realize the benefits from up-front considerations of the FARs and engagement with 
FAA approvers. The PSCP should be submitted to the FAA as soon as possible after the design 
concept is firm. The PSCP needs to be submitted in advance of any requests to FAA for conformity 
inspections, test plans review, or compliance data reviews. 

The remainder of this document describes the generalized content of the PSCP and provides 
TASAR-specific context where appropriate. A high-level Compliance Check List is provided as 
an input to the as-yet-to-be-determined certification and operational approval project of the 
TASAR EFB flight-deck application. 

4.2.3.3 Project Specific Certification Plan (PSCP) 

FAA allows a general form of the PSCP to be followed, and numerous similar outlines to this plan 
are documented in various FAA guidance documents. FAA does not impose an exact format to 
this plan and allows latitude to applicants for tailoring the process to their respective needs. 

4.2. 3. 3.1 Certification Phases 

“The FAA and Industry Guide to Product Certification (CPI Guide)” [28], provides a good 
overview of the certification process that is described herein. 

There are five Certification Phases that move from early project concept and initiation through 
post certification activities. The content of the PSCP outlines the FAA and applicant agreement 
and operating practices for a Product Certification project. Each phase is built on early mutual 
awareness of key certification issues, commitment to planning and managing projects, early 
identification and resolution of issues and other elements to achieve the aforementioned vision. 
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All phases contribute to improving safety and serve to mitigate cost and project risk. The five 
phases of certification are; 

1) Conceptual design phase 

2) Requirements definition phase 

3) Compliance planning phase 

4) Implementation phase 

5) Post-certification phase. 

To the extent warranted by the new or revised product (e.g., due its size and complexity) 
considerable up-front engagement of both the FAA and the applicant is a key part of the process 
represented by these certification phases. The certification process described here is applicable for 
all aircraft system certifications, from new aircraft developments to EFB applications. However, 
the process, level of involvement by FAA and the applicant personnel, and complexity of the PSCP 
can vary widely and typically is tailored to meet the objectives to ensure that the new or revised 
product is implemented in a manner to assure the safety of flight operations. 

The key FAA participants in this process are as follows; 

• FAA and applicant’s Management 

o Make commitments to the certification project and provide leadership and 
resources 

• FAA and applicant’s Project Managers 

o Jointly orchestrate the PSCP 

• FAA Standards Staff Project Officer 

o Provides timely standardized policy and guidance 

• FAA Engineers and Designees 

o Apply regulations and policy to find compliance including the determination of 
the adequacy of type design and substantiation data 

• FAA Inspectors and Designees 

o Determine conformity and airworthiness 

• FAA Flight Test Pilots and Designees 

o Conduct FAA flight tests 

• FAA Chief Scientific and Technical Advisor 

o Provides expert advice and technical assistance 

• FAA Aircraft Evaluation Group (AEG) 

o Evaluates conformance to operations and maintenance requirements. 

A more detailed description of the roles of the key players is found in the CPI Guide [28]. 

The following is a description of each of the five certification phases, providing a definition of 
each phase, identifying expected tasks, required information, deliverables, and defining criteria for 
success. Deliverables of each phase are prerequisites before entering the next phase. 
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The following list represents the eriteria that should be applied to all phases of eertifioation to 
ensure success; 

• Mutual trust; confidentiality; meet all commitments; emphasize empowerment 

• Open and timely communication 

• Proper level of technical project and management leadership with frequent reviews to 
maintain awareness of status, significant issues, and commitments 

• Early familiarization meeting(s); meetings with well-structured agendas and presentations 
attended by proper participants 

• Document agreements, issues, actions; agree to clear time frames, expectations, action 
plans 

• Timely, high-quality documentation of decisions, agreements, schedules, milestones, 
action item assignments, compliance/conformance submittals and approvals. 

4.2. 3. 4 TASAR EFB Applications Assumptions 

The following assumptions will influence the certification requirements for TASAR: 

1) TASAR (as currently defined by the TASAR operational concept [1][2], and TAP 
application description [3]) is anticipated to be designated as a “No Safety Effect” EEC. 
This is based on the Operational Hazards and Safety Requirements Analysis in [7], which 
identifies a number of significant hazard mitigations resulting in this designation. 

This failure effects designation is subject to approval by EAA certification and operational 
approval authorities. The highest failure effects designation for TASAR should be limited 
to no greater than “Minor” in the unexpected event that workload issues are deemed an 
issue with TASAR by approval authorities. 

Note: After meeting with EAA, TASAR will be designated as “Minor Effect” due to 
potential pilot workload associated with TASAR due to misleading / bad data 
(Section 4.3). 

2) TASAR is expected to be implemented and hosted on a Class 2 Portable Electronic Device 
(PED). 

TASAR requires a read-only interface to on-board avionics systems, but will not be 
transmitting information to avionics systems. 

TASAR is expected to utilize antennas for accessible information sources via commercially 
available communication data links and associated networks. These antennas may either 
be permanently installed or may be self-mounted. 

3) Eor this certification and operational approval plan (i.e., the PSCP), the TASAR Class 2 
EEB is expected to be installed as a “cockpit mount” in the flight deck. A cockpit mount 
allows for easy insertion and removal of the EFB by the flight crew. A cockpit mount is 
desired compared to a yoke mount, which is a more critical installation. The cockpit mount 
is not to be confused with a fully installed EFB per Class 3 devices, which is not planned 
for TASAR. 
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Note: It is at the discretion of the implementer and end user on whether or not the portable 
TASAR EFB will remain un-mounted or be mounted in the cockpit while in use. 

Note: Per FAA feedback, the only certification requirements would be for mounting / 
installation of the FFB, getting one-way, read-only access to certified systems data 
(e.g., via ARINC 429 busses), and partitioning and protections for non-interference 
with certified systems. The Aircraft Interface Device (AID) is intended to 
accomplish much of this. FAA did not see the need for a PSCP for the TASAR 
software, just for the installation. If they already have an existing installation, then 
the operational approval process is for a user to go directly to their POI (Section 
4.3). 

4) TASAR is expected to utilize an AID to serve as an intermediary interface to avionics 
systems. 

The use of an AID device is not an explicit requirement. However, since the TASAR Class 
2 PFD/FFB is expected to utilize a Commercial-Off-The-Shelf (COTS) computing device, 
an AID is needed to serve as the interface between the PFD and the avionics systems that 
provide information to the TASAR application. Without an AID, the COTS PFD would 
require modification to the commercial product to provide the avionics interface and 
associated interference and security protections on its own. This of course significantly 
reduces the cost benefits of using COTS products to enable FFB applications in the flight 
deck. 

5) The TASAR software application is closely aligned to Type B EFB applications per AC 
120-76C [13]. While not mapping exactly to the Type A or Type B software applications 
as defined in [13], TASAR is well aligned to Type B applications. TASAR is viewed to be 
Type B “Fite”. 

Note: After meeting with FAA, TASAR is viewed to be a Type B application. The 
additional designation as a Type B “Fite” should not be used. Type B designation 
is sufficient (Section 4.3). 

Similar to Type B applications, TASAR utilizes processing algorithms to achieve its 
intended function (i.e., it is not just used for storage and lookup of static database 
information as is the case for Type A applications). 

As additional mitigations for TASAR when compared to Type B applications. Type B 
applications may be used in all phases of flight including flight critical phases. TASAR is 
primarily used in en route operations and during the latter portion of climb and early stages 
of descent operations. More importantly, unlike typical Type B applications, which are 
relied upon to support flight operations, (e.g., providing weight and balance; and aircraft 
performance calculation) the TASAR application’s sole purpose is to seek and provide 
flight path improvement opportunities to the pilot. Thus while similar to Type B 
applications already approved by FAA, TASAR is expected to have a lower threshold to 
meet the safety and operational requirements compared to Type B applications. 

4.2.3. 5 General Use Considerations 

1) Components of the Class 2 EFB include all hardware and software needed to support EFB 
intended functions 
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a. A Class 2 EFB may consist of modular components (e.g., computer processing unit, 
display, controls) 

i. Any EFB hardware not accessible to the flight crew on the flight deck (e.g., 
AID, antenna for aircraft wireless) and/or not portable must be installed in 
accordance with the applicable airworthiness regulations (AC 20-173 [16]) 

2) Class 2 EFBs are typically mounted to the aircraft via a mounting device and may be 
connected to a data source, a hard-wired power source, and an installed antenna (e.g., 
TASAR) 

3) To be considered portable, the EFB must be removable from flight deck without use of 
tools by flight crew 

4.2.3.6 Software-Specific Approval Considerations 

1) Class 2 EFB hardware, internal components, and software do not require FAA 
airworthiness approval 

2) For Portable EFBs, DO-178B does not apply even for minor failure effects 

Note: FAA confirmed that Type B applications running on non-certified hardware (e.g.. 
Class 2 EFB) do not require DO-178B compliance (Section 4.3). 

3) Type A and Type B applications are typically considered as “hosted” because they have no 
requirement to be installed as part of aircraft type design or as an alteration 

a. Such equipment would usually identify the hardware installed as miscellaneous, 
non-required equipment 

4) Portable EFBs are limited to Type A and Type B software applications - the Airport 
Moving Map Display (AMMD) for ground operations is a Type C application and is the 
only current non-Type A or B exception being allowed on portable EFBs 

5) Single or Dual EFB Configurations 

a. Allows for partitioned Operating Systems (OS) and software applications 

i. Separate DO-178B Finux and non-certified Windows OS 

ii. DO-178B approved software applications and non-DO-178B hosted 
software applications allocated to their respective EFB and partitioned OS 

b. “Hosted” and “Approved” software applications 

i. Need to demonstrate that hosted applications (e.g., TASAR) when 
integrated with approved applications do not interfere with them 

6) Downloads of newly revised software applications into the EFB must provide assurance 
(i.e., have a means to verify) that other approved applications are not adversely affected 

7) Type A and Type B software development process does not require DO-178B 

Note: FAA confirmed that Type B applications running on non-certified hardware (e.g.. 
Class 2 EFB) do not require DO-178B compliance (Section 4.3). 
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The following steps are required for software development in this case (i.e., non-DO- 
178B): 

a. Develop and review high-level requirements 

b. Develop architecture on low-level requirements; these do not have to be reviewed 

c. System requirements (all derived) 

d. Prove code meets high level requirements; no structural coverage needed to be 
demonstrated 

e. Ensure that high-level requirements 

i. Comply with system requirements 

ii. Are accurate and consistent 

iii. Are traceable 


4.2.3. 7 Hardware-Specific Approval Considerations 

1) Airworthiness regulations apply to installed EFB components 

a. Do not apply to portable EEB components 

b. Must only address specifications associated with the installed components 

i. Mounting (size and weight) 

ii. Power (maximum electrical load, voltage, and current frequency) 

iii. Data connectivity (input/output data specifications and security) 

2) Class 2 EFB hardware, internal components, and software do not require FAA 
airworthiness approval 

3) EFB components are “installed” when they are incorporated into aircraft type design under 
14 CFR part 21 or as a proper alteration under 14 CFR 43.3 

a. All other EFB components are considered “portable,” regardless of how often they 
are removed from the aircraft 

4) Type A and Type B applications are typically considered as “hosted” because they have no 
requirement to be installed as part of aircraft type design or as an alteration 

a. Such equipment would usually identify the hardware installed as miscellaneous, 
non-required equipment 

5) An alternate view on certification consideration for “Non-Flight” Systems: 

A number of systems may be installed in an aircraft that do not affect the basic flight 
capability of the aircraft. Systems such as 1) passenger entertainment systems, 2) 
information systems, 3) data storage devices, and 4) potentially TASAR may fall into this 
category. 

Certification approval of such systems depends on their function, and the kinds of hazards 
that the system can present to the aircraft. 

Non-flight systems could be for use only on the ground or may be used on both ground and 
while airborne (e.g., TASAR). 
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A primary concern in gaining approval for such systems is that the hardware needs to be 
compatible with the rest of the aircraft and its systems. Testing must ensure that operation 
or failure of the non-flight system does not affeet the safe flight of the aireraft: 

a. in general, units must stay in place during a erash and must not fail in such manner 
to eause a hazard (such as fire or smoke) to the aireraft they are installed in 

b. the function of potentially affeeted systems determines what level of integrity and 
environment testing that must be eompleted to meet the eertifieation and eustomer 
requirements 

e. if failure of the unit has no safety eonsequenee (i.e., effect) then from a certification 
perspective, the unit only has to be shown to be airworthy. 

The eertifieation of non-flight systems as described above is elosely aligned with Class 1 
and Class 2 EFB hardware that support Type A and Type B applications and is expected 
to support TASAR (as a Type-B applieation). 

4.2. 3.8 Project Specific Certification Plan (PSCP) Overview 

The following is a representative outline of a PSCP that is amenable for use with TASAR: 

1) Purpose or Introduction 

Identify the intent of the Certifieation Plan. 

2) Description 

A brief deseription of the system, product and associated applieation should be included or 
submitted as a separate doeument if the design deseription is not yet available in detail or 
is too eomplex. 

3) FARs 

Applieable regulations need to be listed by sections and subsections, including the 
amendment level if it differs from the eertifieation basis established for the product. Any 
plans for exemptions, equivalent levels of safety, or special conditions should be ineluded, 
if known. 

4) Compliance 

Tell how compliance will be shown. Provide analysis results of failures and safety 
performance. Indieate tests, e.g., vendor qualifieation tests, applieant ground tests on test 
rig, ground test on flight test artiele, and flight test. Demonstrate software eomplianee, 
show similarity, demonstrate the design, and provide inspection results. If eomplianee is to 
be through the use of unique methodology, it should be so noted in the certifieation plans 
and should then be eovered by separate submittals and discussions. Compliance data should 
be made a part of the eertifieation plan. 

5) Conformity 

Indieate what parts of the installation eonformity will be required. Ensures that parts are 
built to specifieations. 

6) Data 
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List the data to be submitted to show compliance. It is acceptable to give “to be determined” 
(TBD) report and drawing numbers. 

7) Airplane Flight Manual (AFM) 

Indicate if this document is affected and how it will be revised (or revised as an AFM 
supplement). 

8) Type Certificate Data Sheet 

Indicate if this document is affected and how it will be revised. 

9) Proposed DER(s) 

The project ACO must determine the appropriateness of assigning designees to represent 
the FAA, e.g., the Designated Engineering Representative (DER), Designated 
Manufacturing Inspection Representative (DMIR), Designated Airworthiness 
Representative (DAR), and others as appropriate for each project. The ACO may not 
delegate the authority to approve certain aspects of a project even though a DER may have 
previously been granted authority in that general area. 

10) Master Minimum Equipment List (MMEL) 

Indicate if the MMEE is affected and describe the intended minimum Dispatch 
configuration. 

11) System Criticality 

Eor applicable systems, the results of the preliminary function hazard analysis need to be 
made known, e.g., system criticality, software criticality, functional failure conditions 
summary. 

12) Schedule 

Provide a schedule which shows the following: 

a. Significant milestones 

b. If applicable, identify when a preliminary hazard analysis will be submitted and 
when all detail data submittals will be made: 

i. Descriptive data submittals (drawings) 

ii. Substantiating data submittal (compliance reports) 

iii. Test schedule (when and where), including Type Inspection Authorization 
(TIA), e.g., conformity and airworthiness inspections 

iv. Conformity inspection requests and schedule (parts, systems, and 
installation) 

V. Compliance inspection schedule 
vi. Pinal approval 

After the PAA has indicated concurrence with the PSCP, it is not necessary to reflect the approval 
by revising the report. The letter of concurrence is considered as sufficient evidence. PAA letters 
of concurrence can be used as updates to conditional approvals or to subsequent revisions of the 
PSCP without the need to revise the report, resubmit it and then wait for another PAA letter of 
concurrence. 
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4.2.3. 9 Additional PSCP Activities and Artifacts for TASAR 

The following additional activities and associated artifacts are candidates for further preparatory 
tasks by NASA: 

• Hold an Informational Meeting / Pre-Certification Meeting with appropriate FAA 
personnel prior to launching an actual Certification Project. This would allow comments 
from FAA to be factored into the actual certification. 

Note: This meeting was in fact accomplished since initially recommended (Section 4.3). FAA 
seems open to further engagements with the NASA TASAR team, even without a formal 
applicant. However a formal applicant would be beneficial when in engaging with FAA. 
FAA also suggested engaging with the POI as appropriate. 

• Artifact development pre-Certification Project kickoff: 

1) Some artifacts have already been developed as part of NASA and TASAR team member 
development and analysis effort: 

• Understanding of EFB airworthiness requirements (per this document) 

• TASAR Concept of Operation [1][2], TAP Application Description [3] and 
associated intended function and HMI design 

• Safety Assessment; Analysis of Operational Hazards; Safety Requirements [7] 

• University of Iowa OPT human factors assessment of TASAR in a Boeing 777 
simulation environment 

• Advanced Aerospace Solutions ’ TASAR flight evaluation using a Piaggio Avanti 
PI 80 aircraft in November 2013 [8] . 

2) Remaining, yet to be developed artifacts: 

• A second flight trial of TASAR is expected to be conducted in May 2015 

• Analysis and test results from Advanced Aerospace Solutions’ TASAR flight 
evaluation and demonstration 

• Activities and deliverables identified [28], typically as part of the five-phase PSCP 
process, but only informally with the POI: 

i. Informally complete the steps of the PSCP; FAA seems open to further 
engagements with the NASA TASAR team, even without a formal applicant. 
However a formal applicant would be beneficial when engaging with FAA. 

a. Agreed Type Certification Basis 

1. Detailed Compliance Check List 

2. Demonstration of compliance 

3. Compliance and conformance requirements verification 

a. Completion of analyses, test plan submission, TIA (Type Inspection 
Authorization), conformities, flight test, AEG (Aircraft Evaluation 
Group) evaluations, critical issues resolution plan, and other items 
affecting the completion of the project 

b. Completed test plans/reports, conformity requests, inspections, and 
compliance documentation 

c. Compliance and conformance findings 
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4. Foundation for continued airworthiness activities and certificate 
management for the remainder of the product’s life cycle (this is needed 
once certification approval has been obtained and is on-going life-cycle 
upkeep of the certification 

a. Airworthiness limitations 

b. Maintenance and operations requirements 

c. Design change data 

d. Compliance Summary Document 

e. Type Inspection Report 

f Instructions for Continued Airworthiness 
g. Continued Airworthiness Management Plan 

3) The following is a list of potential deliverables for TASAR: 

i. Software documentation and demonstration: 

Since software process and software development documentation do not 
require DO- 1 78B for TASAR, documentation requirements are not excessive. 

The following steps are required for software development in this case (i.e., 
non-DO-I78B): 

1 . Develop and review high-level requirements 

2. Develop architecture on low-level requirements; these do not have 
to be reviewed 

3. System requirements (all derived) 

4. Prove code meets high level requirements; no structural coverage 
needed to be demonstrated 

5. Ensure that high-level requirements 

a. Comply with system requirements 

b. Are accurate and consistent 

c. Are traceable 

In addition, demonstration or proof of I ) how TASAR does not adversely 
affect other applications that may be integrated in the same EFB, and 2) how 
software revision downloads ensure that operation of the application is not 
adversely affected 

a. Drawings and specifications of “installed” components of the TASAR EFB 
(e.g., aircraft mount, power connection, data connection, antennas, etc.). 
Whether conformity inspections are required is TBD. 

in. Airworthiness tests and results, e.g., electrical load testing of TASAR 
components with aircraft power sources, non-interference testing with 
avionics systems, etc. 

iv. Data that describes the product design for COTS and installed components. 
Electrical and mechanical performance data. Installation specifications. 

Additional NASA / avionics vendor collaboration could be in the following areas: 

I) Validation of requirements 
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2) Growing the TASAR HMI concept to one using a map depicting the flight path, traffic, 
other airspace and environment information for increased pilot situational awareness and 
more effective use of TASAR for 1) operational benefit and 2) for more effective use of 
TASAR by the pilot / flight crew 

Note: NASA ’s update of the TAP HMI, specifically Version 4 (V4) address many of the 
recommendations made here and has been reviewed for impact on certification and 
operational approval, which is discussed in Section 4.2.5. 

3) Next generation TASAR, which includes writing to avionics, e.g., flight route from a 
trajectory change request recommendation to FMS, to reduce pilot workload 

4) Transitioning TASAR from a decision aid making recommendations to a much higher 
integrity application toward supporting Autonomous Flight Rule operations. 

Note: As indicated throughout this document, the TASAR EFB application is a low- 
criticality flight-deck advisory capability and does not require very stringent 
certification and operational approval requirements. Our meeting with FAA 
confirmed the analysis results we provided. However, TASAR is expected to serve 
as an entry level flight-deck capability and can provide the basis for higher cost- 
benefit and higher criticality uses, e.g., for guidance and/or separation assurance 
intended functions. The PSCP guidance documentation in this report, while only 
partially required for TASAR, will be directly applicable for certification and 
operational approval of these more advanced applications that may be derived 
from extensions of TASAR and are thus documented in this report. 

4.2.3.10 Additional TASAR Related Certification Discussion Topics 

After initial certification and operational approval requirements were provided to NASA, NASA 
requested additional perspectives to these following 3 topics: 

Topic #1: Delineation of EFB Software V5. EFB Hardware Approval Requirements 

NASA requested clarification and further input on the somewhat blurry line between approvals of 
EFB software vs. EFB hardware. Also, since some operators will already have EFBs installed 
(with appropriate approvals) and may wish to consider TASAR as an add-on application, it would 
help to clarify the “delta” approvals required in this case. 

Response: With respect to the blurry line between EFB hardware and software, it is actually quite 
clear. For Type A and B applications, there are no software airworthiness requirements. Per FAA 
feedback (Section 4.3) TASAR is designated as a Type B application (related to performance and 
planning calculations), and thus falls into this category. 

From the hardware perspective, only installed elements of the EFB require airworthiness 
approval, e.g., the mounting, data connection (to avionics via an Aircraft Interface Device), 
connection to aircraft power, and internet communications via data links. AC 20-173 [16] 
provides the airworthiness requirements and points to other associated tests. The FED aspects of 
the EFB do not require airworthiness approval. 

If hardware is already in place, this will have already undergone airworthiness approval of the 
installed components. No other airworthiness approvals will be needed. In the event any aspect of 
the hardware is not the same as the original installation, an applicant needs to show similarity to 
the initial installation and note what has changed and indicate how the change may ajfect things. 
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An example could be if a higher bus speed is used in the new installation (i.e., Mega-bits or Giga- 
bits per second). This could alter the sensitivity to EMI and one may have to retest those aspects 
and any other changes to installed components to ensure continued airworthiness. 

From a software point of view, this will depend on what software functionality is preexisting and 
how TASAR is expected to be integrated into the existing software system (i.e., other already 
existing applications and the Operating System). If existing applications are also “hosted”, i.e., 
other Type A and B applications, then adding TASAR should not require any additional or sign- 
ificant precautions as software airworthiness is not required. Considerations would be whether 
one application will be performed at a time or if multiple concurrent applications would be in use. 
Some applications may run in the foreground, others could be running as background loops. 
However, while existing applications may serve as paper replacement or provide performance 
calculations, it is likely that one must show that TASAR (or any other new application) does not 
interfere with those applications (although no DO-I78B process is required here). 

If TASAR software is integrated with “approved” software (i.e., those developed and approved via 
DO-I78B and likely supplementing some of the aircraft communications, navigation, and 
surveillance (CNS) functions), this has considerably more significant impact on ensuring that 
TASAR does not interfere in this case. Likely some appropriate level of partitioning will be needed 
(e.g., time partitioning, one application executing at a time, memory partitioning, separate OS’s, 
separate EFB processors, etc.). As more and more FEB applications find their way on-board the 
aircraft, some being “hosted” with others being “approved, ” a partitioned EFB system approach, 
e.g., a dual EFB processor system, would likely be needed, requiring, for example, a DO- 1 78B 
certified OS for approved applications, while a non-DO-1 78B OS could be used for the hosted 
applications. An AID will also be required to enable any interfaces to aircraft systems and 
avionics. 

Topic #2: Typical Duration of Certification and Operational Approval Process 

NASA Request #2: For similar-sized projects (i.e., other Type B applications) how long does 
certification and operational approval typically take; what issues must typically be dealt with? 

Response: Rockwell Collins has been working EFB-like products since at least 1999. Common to 
all of these product initiatives (whether or not they resulted in actual products), these development 
efforts laid initial groundwork on providing internet connectivity in the aircraft, providing 
information servers, services, and attendant applications for cockpit and cabin use, and performed 
the necessary steps toward certification and operational approval. Meetings were held with FAA, 
wherein engineering and certification personnel presented these development efforts, their plans 
for certification (i.e., certification project plans), and activities that had already been completed 
and were planned to be included as part of the approval process. 

An important point to consider is that when going to the FAA for the actual start of the certification 
project, much of the planning and homework can and should already have been accomplished for 
this level of certification (i.e., lower criticality levels of minor or below). This was confirmed by 
FAA at our technical interchange meeting (Section 4.3) and this should also be done for a TASAR 
Certification Project. 

While no firm baseline estimates are available in terms of time and effort required, in consultation 
with DERs, typically the engineering effort for a project commences with either receiving or 
developing the requirements for the system being planned for development. Software and 
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hardware development processes are initiated, including their subsequent integration. Thus while 
application software development is ongoing, the development / acquisition of the AID, and 
installation of “installed components ” would take place. Only minimal effort is required for the 
FED EFB as it is expected to be COTS. 

While the software and hardware developments are ongoing, the PSCP with associated artifacts 
is also being developed. Once the PSCP is completed (from the applicant’s perspective), FAA is 
approached for commencing the Certification Project with the applicant. 

Note: Based on the FAA meeting, for EFB applieations such as TASAR (i.e., Type B), the PSCP 

is not of primary importance and may not even be required. FAA noted that the applicant 
may be able to engage directly with the POI for approval of the EFB mount and for 
previously installed EFB components (Section 4.3). 

A notional 3-month certification time period is envisioned for TASAR, which represents the time 
period for periodic engagements with FAA in engaging with the POI and/or executing the PSCP 
(if utilized). If the initial inputs from the applicant indicate that the applicant has done homework 
and provided the required artifacts, the POI could allow use of the TASAR application in very 
short order (in the matter of a couple of weeks), allowing the go-ahead for the 6-month flight-use 
validation period with corresponding data collection. The validation time period may be shortened 
via approval by FAA for certification projects that are not excessively complex (in terms of 
certification level and/or no significantly new technologies or approaches being involved). TASAR 
would have good potential for a shortened validation period, but this is TBD with FAA. If the 
evaluation period is uneventful, then the operator will likely achieve full approval for use once the 
evaluation period is completed and a report documenting the results of this period is completed 
by the applicant and accepted by FAA. While this 3-month certification estimate is somewhat 
subjective (especially in lieu of the 6-month evaluation period), based on the successful meeting 
with FAA and feedback received, this 3 -month estimate seems reasonable. A TASAR certification 
program should be relatively easy to achieve since it does not require certification of new 
technologies and has a low certification threshold (i.e., “Minor Effect” FEC). 

Topic #3: Concluding Set of Recommendations 

NASA Request #3: What further steps NASA could/should take without an actual applicant (e.g., 
an airline) or specific implementation (e.g., identified aircraft) to reduce the certification time and 
risk when such an applicant shows up. What materials can/should be developed that are not 
applicant specific? Are there additional steps a NASA/avionics vendor partnership could 
accomplish without an applicant? 

Response: Section 4.2 and 4.3 and associated Appendices B and C provide significant certification 
and operational approval information, including inputs on the PSCP and DER feedback (which 
will be presented in the next section {Section 4.2}). Since the scope of the current work effort does 
not include the actual certification and approval of TASAR, actual certification and operational 
approval was not pursued here. However, significant details have been provided concerning the 
specific steps and associated artifacts that must be followed in achieving approval of the TASAR 
EFB application as a flight-deck advisory system. Specific recommendations have already been 
provided in Section 4. 2. 3. 9 above under “Remaining, yet to be developed artifacts. ” 

This section examined FAA guidelines and regulatory requirements needed for the certification 
and operational approval of the TASAR EFB flight-deck application and provided a conceptual 
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plan expected to lead to successful certification and operational approval of TASAR. The next 
section provides results of a “dry run” review of these requirements with in-house DERs at 
Rockwell Collins. 

4.2.4 DER "Dry Run" Review of Certification and Operational Approval Artifacts 

This section examines elements associated with the certification and approval processes as they 
apply to the TASAR EFB application, which underwent a preliminary review with DERs for 
feedback whether the certification basis and means of compliance for approvals are appropriate. 
Specifically, this describes the following: 

1) Representative artifacts and considerations of the TASAR certification and operational 
approval processes 

2) A preliminary DER review, i.e., “dry run” of these artifacts and requirements 

3) Results of this DER review, including feedback and recommended updates to these 
artifacts and certification requirements. 

4.2.4.1 TASAR Artifacts Developed for DER Review 

The majority of certification and operational approval artifacts utilized in the DER dry run reviews 
have already been discussed in Section 4.2.3 above. This section identifies additional artifacts that 
are more specific in nature and are provided in more detail in Appendix D. 

Appendix D consists of several sub-appendices as follows: 

• D.l DO- 178B Objectives Artifacts Requirements for Level D 

• D.2 Tabletop EFB Evaluation (Detailed Check List #1) 

• D.3 EFB Operational Evaluation (Detailed Check List #2) 

• D.4 EFB Report Information Template 

• D.5 EFB Line Evaluation Job Aid (Detailed Check List #4). 

The DER reviewers represented both software and hardware certification disciplines and expertise. 
In general, without exceptions, DER reviewers were in concurrence with the information presented 
to them for TASAR certification requirements and offered additional advice, clarification, and 
perspective on a number of points as presented herein. 

The following certification and operational approval artifacts and requirements were included in 
the information package discussed with the DER reviewers: 

1) Overview of the certification and operational approval plan (i.e., PSCP) 

a. Consisted of a brief overview of the five phases of the PSCP, i.e., conceptual 
design, requirements, compliance planning, implementation, and post certification 
phases 

b. Brief review of the typical content of a PSCP 

c. Review of the PSCP as applied to TASAR 

2) Review of cornerstone EFB documents (FARs, regulatory, and guidance) 

3) Certification approval considerations for the TASAR EFB application 

a. TASAR EFB application assumptions 

b. Review of current industry trends for EFB applications 
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c. Key points and observations related to TASAR EFB eertification approval 

d. Software-specific approval considerations and compliance 

e. Hardware-specific approval considerations and compliance 

In addition to reviewing the above topics associated with achieving certification approval, the DER 
review also included several additional topics: 

1) Discussed designee process used by EAA and responsibilities of the operator and EAA in 
the approval process 

2) Discussed the TC, SIC, ISO Authorization, Parts Manufacturer Approval (PMA), and the 
role of Conformity inspections 

a. Type Design data (and processes) focused on the “Build” of the EFB system 

b. Qualification data (and processes) focused on the “Airworthiness” of the EFB 
system. 

3) Role of DO-178B for EFB applications like TASAR 

4) Some potential risk reduction methods for: 

c. Use of partitioning of system components to manage risks due to EFB system 
failures 

d. Security considerations 

e. Software revision considerations 


4.2A.2 DER Dry Run Review- Process Overview, Artifacts Discussion, and 
Feedback 

The review of the TASAR certification operational approval artifacts from Section 4.2.4. 1 was 
held with two experienced engineers from Rockwell Collins’ Certification Support Organization. 
One engineer is a DER designee with responsibilities related to certification of software-intensive 
systems. The other engineer is a soon to be “Systems and Equipment Unit Member” designee and 
is a subject matter expert in the area of certification of hardware-intensive systems. 

Note 1: EAA is currently in the process of making changes to the “designee process” for 
approvals and is creating an Organizational Designation Authorization (ODA) Unit 
Member (UM) process. As it currently stands many DERs will eventually become Unit 
Members (UMs) with specialization in software, hardware, and/or systems. 

Note 2: NASA has strong interest for further development and maturation of the TASAR EFB 
application and would ultimately like to see TASAR fielded as a flight-deck capability 
to provide flight path recommendations to the pilot, with the expectation to attain 
operational benefits for the end user operator. This will require gaining certification and 
operational approval from EAA and/or associated designees. The above mentioned 
requirements and artifacts from the subsections of Section 4.2 in this report and 
associated appendices are expected to be needed to determine the certification basis for 
TASAR and to provide the means for compliance for TASAR operational approval. As 
such, this project does not constitute an actual Certification Project and approval on its 
own but should enable a direct path to such approvals. 

The DER review meeting commenced with a statement of the objective of the meeting, which was 
to present, review, and provide feedback on the information and artifacts that had been developed 
to identify and address TASAR-specific certification and operational approval requirements. The 
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TASAR operational concept and intended function were also briefly reviewed to provide context 
to the DER review. References to previous analyses that were already conducted that are relevant 
to the certification approval process addressed in the subsections of Section 4.2 were noted along 
with results of the major findings of these analyses. 

The following topics were presented to and discussed with the DERs. 

4.2. 4.3 Overview of the Certification and Operational Approval Plan 

The five phases of the certification process as provided by EAA guidance and the PSCP [27] [28], 
both as a general review, and then with a TASAR-specific view of the PSCP, were presented as 
part of the DER dry run review. 

DER Feedback: The DERs were in concurrence with the five-phase certification process. The 
DERs were also agreed that the PSCP elements had been adequately addressed at a high-level, 
including the TASAR-specific elements that were presented. It is noted that the TASAR-specific 
PSCP were limited to some but not all artifacts, since a fully executed TASAR PSCP would require 
completion of all steps to a sufficient level of detail and verification to achieve approval of an 
actual certification of the TASAR product, which is beyond the scope of this study. 

4.2. 4.4 Review of Cornerstone EFB FARs, Regulatory, and Guidance Documents 

The following were identified as key documents that are fundamental to be considered for the 
certification of EEB products and applications; 

The cornerstone EARs, regulatory and guidance documents for EEBs are as follows 

1) Title 14 of the Code of Eederal Regulations (14 CER) parts 21, 23, 25, 27, 29, 43, 91E, 
91K, 121, 125, and 135 [29] 

2) Elight Standards Information System (ESIMS) - 8900.1 Change 47, Vol. 4, Chapter 15 - 
EEB Operational Authorization Process [14] 

3) AC 120-76C, Guidelines for the Certification, Airworthiness, and Operational Approval of 
Electronic Elight Bag Computing Devices [13] 

4) AC 20-173, Installation of Electronic Elight Bag Components [16] 

5) EAA Order 81 10.4C, Type Certification [27] 

6) AC 21-16E, RTCA Document DO- 160 “Environmental Conditions and Test Procedures 
for Airborne Equipment” [17] 

7) AC 20-115, RTCA DO-178B, Software Considerations in Airborne Systems and 
Equipment Certification [20] 

Note; A number of documents provide elements of potential additional approval requirements, 
i.e., compliance to certification requirements. These are primarily associated with hardware 
aspects of EEBs. 

DER Feedback: The DERs agreed that this list represents the key documents that need to be 
carefully reviewed for deriving certification requirements that if met, will demonstrate knowledge 
and compliance by the applicant to EAA reviewers. 
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4.2A.5 Certification Approval Considerations for the TASAR EFB Application 

This section describes information provided to the DERs in a number of areas: 1) TASAR EFB 
assumptions affecting certification, 2) current industry trends for EFB applications, 3) key points 
and observations that affect TASAR certification, and 4) software-specific and 5) hardware- 
specific approval considerations for TASAR EFB compliance to the regulations. 

4.2.4. 5.1 TASAR EFB Assumptions Affecting Certification 

The following TASAR EFB assumptions were presented to the DERs for consideration as part of 
the certification and approval process review: 

1) Based on the Operational Hazards and Safety Requirements Analysis in [7], TASAR (as 
currently defined is anticipated to be designated as a “No Safety Effect” EEC, and should 
be limited to no greater than “Minor Effect” in the unexpected event that workload issues 
come to the forefront 

2) TASAR is expected to be implemented as a Class 2 FED / portable EFB, with a read-only 
interface to on-board avionics systems, and will utilize antennas for accessible information 
sources via commercially available communication data links and networks 

3) TASAR Class 2 EFB is expected to be installed as a “cockpit mount” in the flight deck 

4) TASAR is expected to utilize an AID to serve as an intermediary interface to avionics 
systems 

5) TASAR is viewed to be a Type B application. 

DER Feedback: The DERs were in agreement with the assumptions noted in this section, without 
any corrective feedback or significant counterpoints. 

4.2.4. 5. 2 Current Industry Trends for EFB Applications 

Current trends for EFB applications were reviewed with the DERs and are summarized as follows: 

1 ) EFBs and their software applications provide (or are expected to provide) a retrofit path 
for new, and increasingly more capable flight deck capabilities 

a. The increased ability of COTS PEDs is providing impetus to add new capabilities 
economically 

b. FAA has been relatively flexible in approving EFB applications but at times has 
become rigid in terms of what it is willing to allow for EFB implementations 

2) Airlines are beginning to see cost benefits of EFBs, often with different business cases to 
equip. They see reduced pilot workload, simplified flight operations, and greater situational 
awareness as key benefits. 

3) EFBs are becoming an essential tool in the flight deck, improving situational awareness 
and leading to improved pilot decision making. They allow the flight crew to connect in 
real time to rest of world (e.g. TASAR via data link connectivity to internet information 
sources for weather, traffic, airspace status data, etc.). 

4) Currently, EFB requirements are in a state of flux. Some companies, in applying for 
certification approval, fall short of meeting FAA’s intended requirements. This at times 
results in FAA implementing new changes and adding new requirements. 

5) While EFB hardware requirements and specifications are important, the future of EFBs is 
expected to largely depend on the capabilities offered by software applications. 
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a. EFB hardware is expected to become commoditized. 

b. Shift is towards development of more robust software applications. 

6) Latest technological development for Class 2 EFBs is their ability to interface with aircraft 
systems and to provide an access point to wireless communications pipelines (similar to 
those planned for TASAR data connectivity). 

7) Once ADS-B IN becomes available for display in aircraft, benefits of EFB become 
significant. 

a. However, this raises the stakes for EFB software applications, which may go 
beyond Type A and Type B and may affect higher EEC (no longer “Minor Effect” 
or less). 

8) TASAR is most closely aligned with Type B applications. 

a. Consists of processing algorithms to provide recommended trajectory change 
requests to the pilot 

b. TASAR is expected to be less critical than Type B applications associated with 
weight and balance and performance calculations. 

9) While Class 1, 2, and 3 EFBs may be Windows XP -based, and Class 3 EFBs are generally 
the same as Class 2 EFBs in terms of hardware. Class 3 EFBs require more rigorous testing 
to meet FAA qualifications test. 

10) Second generation EFB software continues to seek improved design to incorporate 
common workflow requirements, seeking reduced training time, and reduced number of 
touches, allowing more time for other tasks. 

11) There is a likelihood that EFB systems with hosted Type A and Type B applications and 
with approved software (those designed using DO-178B) will be integrated in some 
installations. 

a. This likely requires a dual processor EFB architecture, allowing partitioning of 
higher and lower criticality software applications 

i. e.g., “approved” (i.e. DO-178B certified) software applications to be 
allocated to one EFB processor running DO-178B-certified Linux OS, and 
Type A and Type B “hosted” applications (developed without using DO- 
178B) running on a non-certified Windows OS (alternate architectures and 
approaches can be considered if equivalent in robustness). 

12) TASAR, as a hosted application, may be integrated with other software applications (some 
hosted and perhaps some approved) and may be installed in a variety of EFB platforms 
including some with certified OS. The manner of integration and hosting of TASAR may 
affect the software certification requirements of its design. 

DER Feedback: The DERs were in general agreement with the current trends in EFB applications 
without any corrective feedback or significant counterpoints. 
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4.2.4. 5. 3 Key Points and Observations Related to TASAR Cert. Approval 

The following were noted to the DERs as being important elements of the certification process for 
TASAR: 

1) The authorization process intended is for Part 121, 125, and 135 operations and require 
authorization from the FAA Principal Inspector (PI). 

a. Part 9 IF operators do not require specific authorization for EFB operations, since 
TASAR does not replace any required systems. 

2) Installed components of a Class 2 EFB (intended for TASAR) require approval as part of 
TC, ATC, STC, and ASTC via PMA. This allows FAA 145 repair stations to test, repair, 
and place a FAA serviceable tag on equipment. 

3) Type A and Type B applications do not require DO-178B certification for applications 
software nor OS for Class 2 EFBs. 

4) Airworthiness regulations only apply to installed EFB components and do not apply to 
portable EFB components (i.e., in reference to hardware). 

a. Installed components for TASAR Class 2 EFB would include the mount (size and 
weight), power (maximum electrical load, voltage, and current frequency), and data 
connectivity (input/output data specifications and security). 

5) Components of the Class 2 EFB include all hardware and software needed to support the 
EFB intended function. 

a. Any EFB hardware not accessible to the flight crew on the flight deck (e.g., AID, 
antenna(s) for aircraft wireless), or not being portable must be installed in 
accordance with applicable airworthiness regulations (per AC 20-173 [16]). 

6) Class 2 EFB hardware, internal components, and software do not require FAA 
airworthiness approval. 

a. Type A and Type B applications are considered “hosted” because they have no 
requirement to be installed as part of an aircraft type design or as an alteration. 

i. Such equipment would usually identify the hardware as miscellaneous, non- 
required equipment. 

DER Feedback: The DERs were in general agreement with the elements identified in this section 
without any corrective feedback or significant counterpoints. 

4.2.4. 5.4 Software-Specific Approval Considerations 

With TASAR being a software application hosted on an EFB platform, the DER review and 
associated discussions paid particular focus to software and its associated development 
requirements. As noted earlier in Section 4. 2. 3. 6, “hosted" Type-B applications actually do not 
require airworthiness approval. In other words, these applications can be developed outside the 
development process specified by DO-178B, even for Design Assurance Fevel (DAE) “D.” 

DER Feedback: As part of the DER review, there was considerable discussion about the extent 
and rigor required for software development of an EFB application such as TASAR. 

At a minimum, the following steps were identified as being required for development of TASAR 
software, which does not required DO-178B: 

1) Develop and review high-level requirements of the TASAR application software. 
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2) Develop the software system architecture based on low-level requirements. The low-level 
requirements do not need to be reviewed as part of any verification process. 

3) Determine derived system requirements. 

4) Prove that code meets high level requirements. No structural coverage needs to be 
demonstrated. 

5) Ensure that high-level requirements: 

a. Comply with system requirements 

b. Are accurate and consistent 

c. Are traceable. 

The software development process for software similar to TASAR has rather minimal 
requirements associated with it in terms of rigor, artifacts, review process, and verification. The 
DERs recommended that one should strongly consider whether and the extent to which elements 
of the DO-178B process, particularly with respect to DAL D should be utilized. In the event of 
future updates and revision of the TASAR concept that could lead to a DO-178B requirement, by 
developing portions of the TASAR software using DAL D, one could make reuse of the code that 
has been developed to this DAL. 

DO-178B DAL D has a requirement to meet 28 objectives for the various software development 
steps. These are described in Appendix D.l for reference. 

In summary, ELB software applications such as TASAR have a relatively low threshold of 
development required and do not require DO-178B to be applied. However, good software 
practices should be followed and depending on future reuse in higher certification levels, one may 
want to consider development of this software to DO-178B DAL Level D. 

4.2.4. 5. 5 Hardware-Specific Approval Considerations 

While TASAR is a software-enabled ELB application, the majority of certification-related 
requirement for compliance for the TASAR ELB system fall into the hardware domain. 

Airworthiness regulations apply to installed ELB components and do not apply to the portable ELB 
components, including internal components of the ELB. Lor the TASAR ELB system, this 
primarily involves the installed components related to the following: 

1) Mounting (size and weight) 

2) Power (maximum electrical load, voltage, and current frequency) 

3) Data connectivity (input/output data specifications and security). 

ELB components are “installed” when they are incorporated into aircraft type design under 14 
CLR part 2 1 or as a proper alteration under 1 4 CLR 43.3. All other ELB components are considered 
“portable,” regardless of how often they are removed from the aircraft. 

ELBs may consist of modular components (e.g., computer processing unit, display, controls). Any 
ELB hardware not accessible on the flight deck by the flight crew or not portable must be installed 
and certificated equipment covered by a TC, amended TC, or STC. The one exception to being 
accessible on the flight deck is a remotely mounted antenna that provides signal reception to the 
ELB. The AID falls into this category of being installed and requiring type certification. 
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Major Class 2 EFB components (motherboards, processors, random aecess memory, video cards, 
hard drives, power supplies and connections) must be configuration controlled, with any changes 
requiring reevaluation to demonstrate that the intended funetion is still met, i.e., non-interferenee, 
and reliability requirements are still met. For sealed components one should use the manufacturer 
model / part number. 

The following high-level hardware requirements are obtained from ^'Flight Standards Information 
System (FSIMS) - 8900.1 Change 47, Vol. 4, Chapter 15 - EFB Operational Authorization 
Process” [14]: 

A. With respect to the FFB display, e.g., TASAR, requirements must be met for legibility, 
brightness, viewing angle, ete., along with requirements assoeiated with input deviees (e.g., 
stylus, digitizer pen, touchsereen). 

The following hardware test requirements must be addressed, as applieable, to the use of the 
EFB system: 

B. Rapid Deeompression (RD) Testing 

(should not be a significant consideration for TASAR) 

C. Eleetromagnetic Interference / Non-Interferenee Testing 
(also required for TASAR as a T-PED) 

D. Antennas airworthiness requirements 

E. Power Sourees airworthiness requirements 

(TASAR likely to use aireraft power, but not a firm requirement) 

a) Battery primary 

b) Battery maintenance 

e) Aircraft secondary power 
d) Aircraft primary power 

F. Data Connectivity (Class 2 Only) airworthiness requirements (required for TASAR) 

G. Data Loading/Database Changes airworthiness requirements 

(TBD for TASAR; likely not a safety requirement but a usability requirement) 

1 , Class 1 or 2 EFBs must have a reliable means for revising the EFB databases 

1. Database currency is determined by what required aeronautical information the 
EFB is replacing. 

2. Each method of data revision must ensure integrity of the data being loaded and not 
negatively impact the reliability of EFB operation. 

3. Proeedures must exist to proteet the EFB from eorruption, espeeially when internet 
and/or wireless means are used. 

4. Database revision does not include applieation software or operating system 
changes. 

5. Applieation software and/or operating system program changes must be controlled 
and tested prior to use in flight. 

6. Database and/or application software ehanges may not be performed during 
operations (taxi, takeoff, in-flight, landing). 
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Note: External drives for data loading are considered ancillary EFB equipment 
and not subject to specific requirements beyond those identified for data 
loading/database revision above. 

H. Mounting Devices (Class 2 Only) airworthiness requirement (likely required for TASAR) 

The EEB, when attached to its appropriately designed mounting device, must be evaluated 
to ensure operational suitability in all ground and flight operations and conditions (airborne 
use for TASAR). 

a) When attached to its mounting device, the EFB must not interfere with flight crew 
duties and must be easily and safely stowed when not in use. 

b) The attached EFB must not obstruct flight crew primary and secondary fields of view 
(See AC 120-76C). 

c) The attached EFB must not impede safe egress. 

The above hardware requirements represent an overview of high-level hardware requirements 
needed to be met to demonstrate compliance with the FARs, regulatory and guidance documents 
for EFB systems. More specific requirements are found in AC 20-173, Installation of Electronic 
Flight Bag Components [16] and AC 21-16, RTCA Document DO- 160 “Environmental Conditions 
and Test Procedures for Airborne Equipment [17]. 

DER Feedback: The DERs were in general agreement with the elements identified in this section 
without any corrective feedback or significant counterpoints. 

4.2. 4.6 DER Feedback 

In general the DERs were satisfied with the level of compliance requirements presented toward 
the certification of EFB systems such as the TASAR EFB application, relative to the information 
provided and with respect to software and hardware aspects of EFBs. No major areas of concern 
of significant counterpoints were raised. 

The DERs did offer some additional perspective in the following areas: 

I . Discussed designee process used by FAA and responsibilities of the operator and FAA in 
the approval process 

2. Discussed the TC, STC, TSO Authorization, PMA, and the role of Conformity inspections 

3. Some potential risk reduction methods 

4.2.4. 6.1 FAA Designee Process 

FAA utilizes the ‘Designee Process’ as an extension to their certification and operational approval 
organizations (e.g.. Aircraft Certification Office {ACO} also referred to as AIR; Flight Standards 
{AES}, the Aircraft Evaluation Group {AEG}, Manufacturing Inspection District Office {MIDO}, 
and others. Organizations and individuals with demonstrated expertise can be appointed as 
approval designees for portions of the certification approval process. Individuals from engineering 
and manufacturers may receive designee appointment, e.g., DER, DMIR, and DAR, who can 
address either manufacturing or maintenance airworthiness of a product. DERs may be appointed 
to software, hardware, or systems as part of the certification process. DMIRs may serve as 
inspectors of conformity, i.e., that products and associated parts are built to the required 
specifications and process. Designee may come from 3"^ party organizations, be appointed from 
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small shops supporting certification for general aviation or from large manufactures for air 
transports, regional aircraft operators, and high-end business aviation. 

4.2.4. 6. 2 TC, ATC, STC, ASTC, TSOA, PMA, Conformity Context 

There are multiple means to certify a new produet or a revised article. From an EFB system point 
of view, only installed components require a Type Certificate approval. The term Type Certificate 
can encompass a range of approvals, including TC, ATC, STC, and ASTC. 

A TSO is a minimum performance standard, defined by the FAA, used to evaluate an article. An 
article can be a material, part, component, process, or appliance (refer to Title 14, Code of Federal 
Regulations, 21.1(b)(2)). Each TSO covers a certain type of article. When authorized to 
manufacture an article to a TSO standard, this is referred to as a TSO authorization (TSOA). 
Receiving a TSO authorization is both a design and production approval. 

There are two aspects to achieving approval, 1) Type Design Data which contains information and 
data associated with “building the product”, and 2) the “qualification” aspects of the integrity of 
data, including software verifieation, whieh demonstrates “airworthiness.” Manufactures must 
have established and maintain approved quality systems and proeesses to support approvals to 
meet airworthiness requirements. 

Conformity is typieally a ‘one-of-a-kind’ inspeetion of an individual part that is used as part of an 
individual system being certified. When qualified, such a unit is issues an 8130 airworthiness tag. 
Eor a larger number of units being develop, this typically requires a Parts Manufacturer Approval, 
which is typically only issued to larger manufacturers. 

4.2.4. 6. 3 Potential Risk Reduction Methods 

The following three subtopics were discussed with the DERs as part of the DER review: 

1) Use of partitioning of system components to manage risks due to EEB system failures 

2) Seeurity considerations 

3) Software revision considerations 

4.2. 4. 6. 3.1 Partitioning of System Components to Manage Risks Due to EFB Failures 

A key issue when integrating EFB applications such as TASAR with other software applications 
is the potential adverse effects of one application, e.g., the “hosted” typically non-approved 
software application with “approved” certified software applications. Several configurations are 
possible: 

1) TASAR is standalone, with its own dedicated processor (own OS and application 
software) and dedieated display, this is will not require any partitioning or special 
protections 

2) TASAR has its own dedicated proeessor, but shares a common display with other 
“Approved Software” applications / software. Recommended Display Standards, e.g., 
AC 25-11, Electronic Elight Deck Displays (for Part 25 aircraft) [30], and AC 23.13 1 1- 
1, Installation of Electronic Display in Part 23 Airplanes [31] must be followed. 

3) TASAR is hosted with other “approved” software applications in a shared proeessor. In 
this case, approved partitioning techniques must be followed. These techniques are 
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required to guarantee throughput and resources (e.g., memory, hard drive, avionics data, 
etc.) of Approved Software applications. 

As EFB software use continues to increase, a dual EFB architecture, with separate OS and 
application software, segregated by hosted versus approved designations is a likely outcome. 
However it is accomplished, protections of processing time and memory space must be ensured to 
prevent one application from taking over and adversely affecting higher-criticality applications. 

4. 2.4. 6. 3. 2 Security Considerations 

While not expected to be a significant issue for TASAR, which utilizes a read-only interface to 
avionics systems and thus does not transmit and pose a security threat to aircraft systems, the DERs 
noted that security issues are becoming more paramount concerns for FAA. Mitigating techniques 
should be followed, such as maintaining read-only interfaces. In the case of transmit-only 
interfaces where the use of “polling” (e.g., once per second) for received inputs is used to manage 
the interface, techniques should be used to avoid disruption via a transmitter ‘babbling’ 
continuously and thus disrupting the I/O process. 

The DERs noted that for security, one should also address threat scenarios in the safety assessment. 
As currently defined, TASAR is not expected to pose a security threat as it is read-only. 

4.2. 4. 6. 3. 3 Software Revision Considerations 

The DERs provided insight with respect to the field-loading of updated software. A key step in 
this process is that assurance is required that what was loaded into the EFB is what was intended 
to be loaded. Use of checksums via the program itself, or via procedural means are potential 
candidates to assure that proper software and operating systems are loaded into the EFB system. 

4.2.4. 7 DER Review Conclusions 

As noted throughout this section, EFB applications such as TASAR have relatively minimal 
software-specific certification requirements and do not require DO-178B as part of their software 
development process to gain approval. EFB hardware-specific requirements are considerably more 
extensive and apply to the installed portions of the Class 2 EFB. Thus in many ways, EFB approval 
should be relatively straight forward for the TASAR Type B EFB application. 

The DERs were in general agreement with the assessment presented to them for a TASAR-like 
EFB application. They provide some additional perspectives on the certification process related to 
the designee process, type certification, and risk reduction techniques relative to system 
partitioning, security, and the software revision process. 

While TASAR has a relatively low certification approval threshold, gaining full approval for an 
EFB system requires one to address a wide range of approval requirements, as reflected in the 
questionnaires in Appendices D.2 through D5. These questionnaires were reviewed and TASAR- 
specific comments were entered into the questionnaires where applicable. 

4.2.5 TAP HMI Version 4 Certification and Operational Approval Analysis 

This section documents the results of a certification assessment of the Traffic Aware Planner 
(TAP) HMI, Version 4 (V4). The analysis examined all HMI elements that pose a potential 
increase in certification / operational approval requirements, with an emphasis on an assessment 
of regulations that may govern the graphical elements depicting aircraft navigation information 
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(e.g., routes, heading), traffie information, weather and airspaee information, and wind 
information. The analysis includes recommendations, with regulatory reference, on specific HMI 
changes to reduce the threshold for certification and/or operational approval. 

As background to this analysis, TAP represents the software engine of the TASAR EFB 
application that is being developed by NASA Langley Research Center and its research partners 
(refer to Figure 4). The TAP HMI V4 represents the latest version of the pilot interface in using 
the TASAR application, which incorporates updates and enhancements based on pilot feedback 
from 1) a HITL experiment conducted under this contract by the University of Iowa OPL [32], and 
2) a flight evaluation of TASAR in a relevant operational environment conducted by Advanced 
Aerospace Solutions, LLC for NASA under another contract [8]. NASA developed an updated 
TAP HMI user interface, V4, to address comments received and to further mature the effectiveness 
of the TASAR application in terms of situational awareness, workload, and compatibility with 
other on-board flight-deck systems. Pilot comments and feedback from [32] [8] that influenced 
NASA’s update to the TAP HMI leading to V4 are described in Section 4.2. 5. 3. 1.1 below. The 
TAP HMI V4 has undergone a second HITL evaluation [33] to determine its effectiveness of the 
revised HMI design. 

The Operational Hazard and Safety Assessment in Section 4.2.1 has determined a FEC of “Minor 
Effect” (which has also been confirmed by FAA - Section 4.3) for the TASAR EFB Application. 
This section (Section 4.2.5) provides the results of a certification assessment of the TAP HMI V4 
to determine if TAP display elements from V4 continue to be consistent with the “Minor Effect” 
designation of TASAR and to ensure that elements of the V4 HMI do not inadvertently raise any 
undo certification issues. The key guidance documents forming the basis of the certification and 
operational approval assessment of the TAP HMI V4 were FAA AC 120-76B [34] and Flight 
Standards Information System (FSIMS) - 8900.1 Change 47, Vol. 4, Chapter 15 - EFB 
Operational Authorization Process [14]. An updated version of AC 120-76, Version C [13] was 
reviewed to determine if any significant updates may affect the TASAR EFB certification 
assessment, particularly pertaining to the revisions made to the TAP HMI in V4. 

4.2. 5.1 TASAR HMI Requirements Assessment 

While the TASAR EFB application has been designated with a “Minor Effect” FEC, this 
designation is silent with respect to the specific requirements to the TAP HMI. The following 
sections address HMI-specific approval considerations. 

4.2. 5. 1.1 Display of Own Ship and Proximate Traffic Awareness 

A key certification issue related to the EFB display of map, route, and / or traffic information is 
the depiction of own ship as part of the EFB application. FAA AC 120-76B [34] was strict in its 
view of depiction of own ship on the EFB display, forcing a “Major Effect” designation if own 
ship was displayed. FAA AC 120-76C [13] relaxes this requirement somewhat by allowing display 
of own ship in certain cases. Reference [13] allows the display of own ship on the EFB display 
when the aircraft is operating on the airport surface at speeds less than 80 knots. From [13] display 
of own ship is only allowed as an aid to situational awareness and is not authorized for use for 
surface navigation, surface alerting, time -based operations, guidance, maneuvering and control 
functions. Display of own ship on the airport surface as a Type B application is intended to help 
flight crews orient themselves on the airport chart / map, and to improve pilot positional awareness 
during taxi takeoff and upon landing. Type B EFB applications using display of own ship position 
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on the airport surface are not of sufficient certification pedigree to be used as the basis for 
operational guidance, maneuvering, and control. 

Display of own ship when operating on the airport surface at speeds of 80 knots or greater, or when 
used in actual flight, elevates the FEC to “Major Effect” with a corresponding increase in software 
certification and operational approval requirements, e.g., requiring approved software per DO- 
178B. 

Erom a TASAR FIMI perspective, display of own ship is not allowed, as the TASAR intended 
function is strictly as an en route advisory tool for the pilot. The TASAR HMI V2 does not display 
own ship nor any other traffic information in any graphical depictions of route information (active 
nor preview of candidate trajectories). 

V4 of the TASAR HMI provides a limited graphical indication of proximate traffic (not including 
its position) in relation to the preview route when the pilot is evaluating route improvement 
candidates using the TASAR Manual Mode. When TAP determines the presence of proximate 
traffic, serving as a traffic hazard, select information regarding this traffic hazard is depicted in the 
Visualization Panel to provide traffic awareness to the pilot. Presence of a traffic hazard would 
likely result in a clearance request being denied due to the traffic in question. 

Own ship is not explicitly shown in the TAP HMI V4 and can only be approximately inferred from 
the EEB display to be located somewhere near the bottom center of the Visualization Panel. The 
TASAR HMI V4, including the TAP Manual Mode, and the depiction of traffic hazards on the 
Visualization Panel are discussed in more detail in Section 4. 2. 3. 2 below. Certification assessment 
analysis results of the TASAR HMI V4 are described in Section 4. 

4.2. 5. 1.2 Other HMI Approval Requirement 

EAA Plight Standards Information System (PSIMS) - 8900.1 Change 47, Vol. 4, Chapter 15 - 
EEB Operational Authorization Process [14] provides specific guidance concerning areas that must 
be addressed by the applicant when requesting approval of an EEB application by the POI, 
including areas related to the HMI. This guidance is provided in the form of a number of 
questionnaires the applicant must answer for review by Plight Standards / POI to gain operational 
approval for the EEB application. 

The following represents a summary of the specific focus areas of EEB HMI design as indicated 
by the EEB Evaluation Checklist 1 Questionnaire per Figure 4-79 [14] and provided in detail in 
Appendix D (D.l) that the operator must address with the POI pertaining to EFB display of 
information, i.e., the pilot Human Machine Interface. 

Checklist 1 represents the Tabletop EFB Evaluation that must be demonstrated to the POI. It 
consists of approximately 1 00 questions that must be answered as Yes or No, that describe whether 
the EEB application being considered meets the intended evaluation requirements. 

The checklist starts with 1) EEB hardware questions, then 2) presents general user interface 
questions, and 3) ends with specific application questions (if applicable). The checklist is designed 
so that any question answered as “No” requires a comment that may include, “Not Applicable.” 
After the operator has completed this checklist, the results are documented so the POI can review 
the results with the operator. 
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Hardware-Specific Questions address EFB readability in sunlight, labeling of controls, ease of 
providing inputs, EFB start-up, ability to reboot, ease of comprehension of failure modes 
(identification, annunciation), and ease of recovery when EFB fails. 

General User Interface Questions address the following list of factors; Revision history and 
expiration dates to be clearly presented, responsiveness of EFB to inputs, EFB processing speed, 
use of busy / progress indicators, consistent user interface allowing selection and use of functions 
and navigating the display, display of needed information and ease of access (avoid missing or 
difficult to find information), common actions and timely access to critical functions, standard 
ways to perform common actions, uniformity of display and controls across the application and 
also other applications, color viewing and ability to distinguish in various lighting conditions, color 
coding / shading / highlighting for display of critical information, appropriate use of red and yellow 
colors (only use for warnings and cautions), readability of text (including in low-visibility 
conditions), contrast of text in relation to display background, use of upper and lower case 
frequency, ease of bringing out of view information into view, icon and symbol functions obvious 
and distinguishable / explained by label or other means, etc. 

Application Software-Specific Questions include the following: Ability to quickly and accurately 
find information, consistency of information layout, ease of being able to read high-priority 
information, ease to determine open/active application(s), detection of incorrect information 
formats / data range, and error messages, crew training, etc. 

The detailed Checklist 1 questionnaire is provided in Appendix D (D.l). 

4.2. 5.2 Review of Changes to AC-120- 76C; Potential Effects on TASAR EEC 

As part the TAP HMI V4 certification and operational approval review addressed in this report, 
FAA AC 120-76C [13] was examined for potential updates to approval requirements that could 
have an effect on TASAR (recall that the previous certification and operational approval analysis 
of TASAR were based on AC 120-76B). From this review the following represent notable changes 
from AC 120-76C: 

• AC 120-76C explicitly constrains the use of Type A and B applications to FECs of “Minor 
Effect / Hazard” or less 

Note: TASAR, as previously analyzed and confirmed by FAA approval authorities is a “Minor 
Effect” Type B, Class 2 EFB application. This report reviews TAP HMI V4 to determine 
if any updates adversely impact this designation (refer to Section 4 for results of this 
assessment) 

• FAA clarified the ability and limitations of an applicant with respect to being able to 
display own ship position for their respective EFB application (EFB Class and Software 
Type) 

o Own ship can be displayed only on the airport surface, when operating at less than 
80 knots 

o Own ship cannot be displayed when in flight when using Class 1 and 2 EFBs and 
Type A and B software. In flight display of own ship warrants a “Major Effect / 
Hazard” designation and requires a Class 3 EFB (or avionics) with Type C 
software. 
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o Own ship depiction that is allowed on the surface can only be used for situational 
awareness and not for operational guidance / maneuvering / control of the aircraft. 

Note: TASAR is used during flight above 10,000 ft. altitude and can thus not display own ship 
position without adversely impacting its certification level (i.e., it would elevate the 
certification level to “Major Effect/Hazard” requiring Class 3 EFB / Type C Software 
designation). 

• Section 1 I.e. 4. c [13] notes that “data link EEB functions may display approved sources of 
weather for strategic / flight planning purposes” (thus removing the word “unapproved”) 

• Section 1 1 .e.4.d [13] notes that “data link graphical weather from sources . . . may be from 
approved sources of advisory weather information and can only be used for strategic / flight 
planning purposes. Do not use data link graphical weather information for tactical decisions 
during critical phases of flight, because data quality is uncontrolled for aviation use. Do 
not use data link graphical weather data as a substitute for airborne weather radar or 
thunderstorm detection equipment.” 

Note: The TAP HMI V4 provides weather hazard information for pilot situational awareness but 
does not replace the use of weather radar or thunderstorm detection equipment for tactical 
decisions. Since TAP HMI V4 utilizes display of weather hazard information for pilot 
situational awareness, this aspect is further analyzed in Section 4.3 for any impact on 
TASAR/TAP certification requirements. 

• “Type C software applications are approved by the FAA using RTCA/DO-178 or another 
acceptable means. These are “non-EFB” software applications found in avionics and 
include intended functions for communications, navigation, and surveillance that require 
FAA design, production, and installation approval. Type C applications are approved 
software for surface and airborne functions with a failure condition classification 
considered to be a major hazard or higher.” 

Note: This is not a new requirement from AC 120-76C. However, this requirement continues to 
indicate that applications related to surveillance, e.g., ADS-B enabled Cockpit Display of 
Traffic Information (CDTI) applications fall under the banner of Class 3 EFB (or avionics) 
/ Type C software. Since TAP HMI V4 provides Traffic Hazard situational awareness, this 
aspect is further analyzed in Section 4.2 for any potential impact on TASAR / TAP 
certification requirements. 

4.2. 5.3 Overview and Comparison of TAP HMI V2 and V4 

Before describing an overview and comparison of the TAP HMI V2 and V4, the next section 
summarizes some of the factors that led NASA to redesign the TAP HMI, leading to V4, which is 
analyzed in this report. 

4.2. 5. 3.1 Summary of Pilot Comments and Feedback on TASAR TAP HMI 

As aheady noted, TASAR and TAP HMI V2 was already analyzed in a HITE experiment (HITE- 
1 [32]), which served to inform the subsequent TASAR flight trial by Advanced Aerospace 
Solutions, EEC [8]. [32] and [8] provided pilot comments and feedback on the TAP HMI, which 
are summarized in the next sections. 


4.2. 5. 3. 1 . 1 Pilot Comments, Feedback on TAP HMI from HITL-1 and TASAR Flight Trial 
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The following summarize pilot feedbaek from HITL-1 [32] (Section 4. 2. 5. 3. 1.1.1) and the initial 
TASAR Flight Trial [8] (Section 4. 2. 5. 3. 1.1.2). 

4.2.5.3. 1.1.1 HITL-1 Feedback on TAP HMI V2 

The results of the post-simulation questionnaire from HITL-1 [32] clearly indicate that the 
participants found the TAP interface easy to work with and useful to very useful. The participants 
generally rated the screen elements as useful to very useful and overall easy to understand. A few 
outliers existed concerning specific screen elements; however, the general consensus of the 
participants was that the TAP display as presented (V2) was useful and easy to use. Many of the 
narrative comments made by the participants directly affected the implementation of the TAP 
interface for the flight trial that was performed subsequent to this experiment [8] and for the 
development of the post-flight trial next generation of the TAP interface, i.e., TAP HMI V4. 

Overall, the TASAR application was very well received by almost all of the pilots in HITL-1. 
Several of them were excited to have such a tool available to them in the cockpit environment and 
felt that is was long overdue to have access to such information. 

From the post-simulation interviews and questionnaires completed by the 12 participants, the 
following comments and feedback on their use of the TAP HMI V2 were received: 

• There was some confusion about two of the button sets available to pilots. The first set of 
buttons causing confusion was the AUTO and MANUAL buttons along the top. The pilots 
indicated that the buttons either need to be removed on some screens (such as the Selected 
Optimization Screen) or grayed out differently to make it clear what screen was still 
available to be selected or which screen was the current one. 

• The buttons across the bottom of the Selected Optimization Screen also caused confusion 
in some pilots. These buttons were there to log the result of asking ATC for a flight path 
request that was generated by the TAP Auto Mode. Several pilots did not see the point of 
having these buttons and would prefer they were not there at all, claiming they did not add 
any value. The fact that these buttons were only visible in some modes caused additional 
confusion. 

• Some pilots wanted to have more information available to them, in particular weather data 
to know why certain optimizations were being made. The pilots felt that it was not 
sufficient to simply know that a route optimization was being impacted by weather. Details 
such as approximate location and time until convective weather was to be encountered on 
the unmodified route are important factors that help give pilot situation awareness. The 
pilots also indicated that future builds of the TAP software should have more uniformity 
between the TAP Auto Mode and TAP Manual Mode screens, including the Route Display. 

4.2. 5. 3. 1.1. 2 Flight Trial Feedback on TAP HMI 

Advanced Aerospace Solutions, LLC conducted an initial flight trial of TASAR [8] with the goal 
to be able to demonstrate and evaluate TASAR functionality in an operational environment and to 
collect pilot assessment data of TAP operation and the TAP HMI. The following represent an 
overview of some of the key feedback received from pilots concerning the TAP HMI used in the 
flight trial (i.e., an updated version of V2 that incorporated some feedback from HITL-1). 
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As with HITL- 1 , pilots in the flight evaluation perceived TAP as easy to use and understand. Likert 
ratings on ease of use generally yielded good scores but allowed room for improvement on route 
visualization and understanding and indicated needed improvements on bearing and distance 
controls. Recommendations of the TAP HMI included: 

1) Better visual depiction of optimized route, 2) request to add new airspace hazard classes 
(e.g., weather, SUA), 3) add speed control into optimizations. 

From the flight test evaluation of TASAR specific comments for possible HMI improvement 
opportunities are as follows: 

• Connection status of individual data connections is not necessary. If there is a problem, 
indicate it and provide ability to go to another screen with more details of the issue. 

• Many pilots had difficulty finding what waypoint was currently set as the optimization 
limit 

• Use color palette that is standardized for commercial aircraft 

• Selected Optimizations need to be easier to set 

• Show a line going around a SUA for better situational awareness 

• Need better map depiction; pilots are generally visual. Show conflicts to be avoided, e.g., 
SUAs 

• It would be nice to know what traffic TAP is considering 

• Verify all suggested routes with map for reasonableness 

• Make map consistent with Navigation Display, also North-up mode 

• Need better visualization tools, i.e., map. Show traffic. 

• Show full route waypoints/names and optimization names vs. 1, 2, 3 

o Show full current route, fix names on map, consider adding a title to every page 

• Yellow text, e.g., SUA should be bold for visibility reasons 

• Make conflicts stand out more; particularly meant for Manual Mode 

• Solution filters need rework or removal 

• Show own ship 

• Intelligently finding off-route waypoints to use 

• Need a more visual tool to select optimization 

• Use touch screen capabilities to find waypoints on map 

• Make it easier to remember to enter the Rejoin Waypoint 

• Make it easier to clear any one part of the optimization 

• Pilots want the “what” and “why” as part of displayed information 

• Consider adding a profile view for vertical change solutions 

• Add fix / bearing / distance tool 

• Many wanted to see winds data 

• TAP functions were well integrated, but a significant amount of inconsistency was noted 
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• Most pilot wanted an alert, although verbally in debrief they were split on whether it should 
be an audible or a pop-up 

• Add voleanic ash advisory areas to avoid 

• Solution filters are not necessary 

• Provide ability to remove a specific constraint (e.g., second off-route waypoint, . . .). 

Based upon pilot comments and feedback from HITL-1 and the TASAR flight trial, NASA 
incorporated many features to the HMI redesign embodied in TAP HMI V4. The next section 
provides an overview of V2 and V4 of the TAP HMI. 

4.2.5.3.2 TAP HMI Overview 

This section provides on overview description and comparison of the NASA-developed TAP HMI 
V2 and V4. TAP HMI V2 underwent an evaluation during the HITL-1 experiment [32], This 
version of the TAP HMI was also used in the initial flight trial evaluation [8]. TAP HMI V4 was 
developed by NASA in response to feedback and lessons learned from HITL-1, the flight trial, and 
additional maturation of the TASAR application. Improvement recommendations, many identified 
in the previous section (Section 4.1) were incorporated into TAP HMI V4. The TAP HMI V4 has 
undergone a second HITL evaluation (HITL-2), which is currently being analyzed. 

TAP capabilities include an Auto Mode and Manual Mode that support the flight crew in receiving 
flight path improvement opportunities to the current flight plan. TAP utilizes on-board data sources 
for 1) aircraft state, FMS active route, etc., 2) ADS-B IN and other sources for traffic information, 
and 3) internet data for wind updates, convective weather hazards, and airspace constraint 
information in order to offer improvement opportunities for fuel and/or time savings. 

In the Auto Mode TAP continually monitors the current flight trajectory and information sources 
to periodically (--1 minute intervals) provide lateral, vertical, and combination lateral/vertical 
trajectory changes that are free of hazards /conflicts, e.g., traffic and weather, and offer fuel 
consumption savings and / or reduced flight times over the current flight plan. Recommended 
trajectories are evaluated for compatibility of ATC constraints (e.g., traffic complexity / density, 
airspace constraints, location within the sector) with the goal to have a higher likelihood of 
clearance approval by ATC. 

The Manual Mode of TAP allows the pilot to request specific trajectory changes for evaluation by 
TAP in seeking route improvement opportunities on their own initiative. In the Manual Mode, the 
pilot enters revisions to the current flight plan for evaluation by TAP. TAP then computes impact 
on fuel consumption and flight time and will also notify the pilot in the event the proposed 
trajectory is subject to traffic or weather hazard constraints. If no hazards or constraints exist and 
fuel and/or time savings can be achieved, the pilot, at his / her discretion can request a clearance 
from ATC for the new flight trajectory. 

Upon power-up of the TASAR application, the pilot inputs initialization of TAP data and reviews 
checklist items to ensure TAP is properly configured and operational. The pilot also established 
the cost index and preferred altitude and cruise speed (e.g., ECON setting) that are compatible 
with the FMS-loaded flight plan. 

4.2. 5. 3. 2.1 Initialization (V2) and Startup Checklist (V4) Screens 
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TAP HMI V2 utilizes an Initialization Screen, shown in Figure 5a, while for TAP HMI V4 the 
initialization screen was redesigned and updates and is referred to as the Startup Checklist Screen, 
which is illustrated in Figure 5b. 

For both versions, V2 and V4, the Initialization Screen (V2) and Startup Checklist Screen (V4) 
appear at startup of the TAP application. 

As illustrated in Figure 5a, the Initialization Screen displays the status of data connections and 
provides data validity checks. Once all items have passed, signified by being green, the pilot then 
accepts the initialization screen. 

The Initialization Screen from V2 was redesigned and enhanced for V4 and is now referred to as 
the Startup Checklist Screen (Figure 5b). The Startup Checklist Screen allows the pilot to perform 
the following tasks: 

1) Ensure that TAP is configured properly 

2) Confirm TAP’s status and settings 

3) Enter, verify, and correct route information for the flight. 


1 TAP 1 Status: Inrtiahzmg | 



inri 

Version: TAPBuiW2.1 


Processor Connection: 

CONNECTED 



Data Connection: 

CONNECTED 



Time: 

PASS 



Ownship State: 

PASS 



FCC: 

PASS 



MCP: 

PASS 



FMS: 

PASS 



Airspace Hazards: 

PASS 



Traffic Hazards: 

PASS 



Atmosphere: 

PASS 


ACCEPT 


Figure 5a TAP HMI V2 Initialization Screen 


The V4 Startup Checklist Screen provides greater integration of initialization items in the V2 
Initialization Screen, eliminating some individual items, and aggregating them more globally. Eor 
example, information sources, e.g.. Time, Own ship State, Elight Control Computer (ECC), Mode 
Control Panel (MCP), and FMS are no longer specifically highlighted and are handled by TAP 
automatically in the back ground. 

The Checklist Complete tab in V4 replaces the Accept button in V2 and ensures that the pilot has 
verified that the correct Navigation Database and TAP versions are being used. The TAP 
Connection tab consolidates the various data sources and indicates that TAP data sources are 
available and operational. The Startup Checklist Screen contains additional information fields that 
are not included in the V2 Initialization Screen, and thus makes more effective use of available 
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display area, while integrating additional pertinent initialization information into one display 
screen. Also included in the Startup Checklist Screen (Figure 5b) are departure and arrival airport 
information and an input that allows the pilot to enter and verify the Route Waypoints along the 
flight plan. The Startup Checklist Screen also allows the pilot to select TAP optimization criteria, 
e.g.. Cost Index, Cruise Altitude and Speed, and provides the Max Optimization Waypoint (WPT), 
representing the waypoint along the route to which TAP should seek trajectory improvement 
opportunities. The Checklist Complete tab allows the pilot to confirm that checklist items have 
been completed. 


Traffic Aware Planner oi«*iiirt 

Startup Checklist 



Figure 5b TAP HMl V4 Startup Checklist Screen 

The V4 Startup Checklist Screen is considerably more consolidated in its information content and 
integrates additional pertinent information in one display screen when compared to the V2 
Initialization Screen. In addition, the use of selection windows (e.g., drop-down/pop-up) and 
keyboard entry allow for clear and easy to use entry and selection of information by the pilot. 

Upon completion of accepting (V2) or completing the checklist (V4), TAP checks whether or not 
the aircraft has achieved an altitude above 10,000 ft. TAP HMI V2 utilizes a Standby Screen 
(Figure 6) that is automatically displayed if the aircraft has not yet reached 10,000 ft. The current 
altitude is displayed to allow the pilot to readily see the flight status relative to the 10,000 ft. 
criteria. TAP HMI V4 eliminates the use of the Standby Screen and automatically transitions to 
the Auto Mode Screen that will be described in the next section. For V4 a “Standing by for 10,000 
ft.” TAP message is displayed in the Message Window of the Auto Mode Screen when the flight 
has not yet reached 10,000 ft. altitude above the ground. 

Once an altitude of 10,000 ft. is reached, V2 transitions from the Standby Screen to the Auto Mode 
Screen, while V4, already using the Auto Mode display, clears the “Standing by for 10,000 ft.” 
message in the Message Window. 
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Figure 6 TAP HMI V2 Standby Screen 
4. 2. 5. 3.2. 2 Auto Mode Screens 

Figure 7 and Figure 9 illustrate the TAP FIMI V2 and V4 Auto Mode Screens, respectively. 
4.2.5.3.2.2.1 TAP HMI V2 Auto Mode Screen 

For V2, the Auto Mode Screen provides designation of Mode (Auto or Manual) in the upper right 
comer, Controls across the top of the display for 1) selecting the number of Off-Route Waypoints 
(maximum of 0, 1 or 2) that TAP uses to compute trajectory improvement opportunities, 2) the 
optimization criteria of Time or Fuel, and 3) thresholds of lbs. of fuel saving and / or time savings 
used for filtering TAP solutions. The lower portion of the V2 Auto Mode Screen provides lateral, 
vertical, and combo (lateral and vertical) solutions on the left side, with outcomes of projected fuel 
and time impact (savings or losses) for each solution along the right side. 

The pilot can select any solution from the V2 Auto Mode Screen and can freeze it for display on 
the Selected Optimization Screen, illustrated in Figure 8, for further assessment prior to making 
an ATC request for a revised clearance of the new trajectory. The Selected Optimization Screen 
displays the selected optimization candidate and its outcomes, along with a listing of the waypoints 
and their Track To heading and Distance on the left side of the display (see Figure 8). The right 
side of the display provides a graphical depiction of lateral and combination views of the trajectory 
being assessed (depicted in blue) for possible request to ATC and also provides the original flight 
plan being followed (depicted in magenta). No graphical view is provided for vertical candidate 
solutions. 
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Figure 7 TAP HMl V2 Auto Mode Screen 
4.2.5.3.2.2.2 TAP HMI V4 Auto Mode Screen 

The TAP HMI V2 Auto Mode Screen has undergone significant revision for the TAP HMI V4 
Auto Mode Screen (see Figure 9). From Figure 9, the V4 Auto Mode Screen consists of three 
panels: 1) the Solutions Panel in the upper left, 2) the Visualization Panel on the right half side, 
and 3) the Optimization Control Panel in the lower left of the Auto Mode Screen. In addition the 
Auto Mode Screen utilizes additional Top Bar and Bottom Bar status and control elements that 
increase pilot awareness of TAP operation (Cruise settings. Data Feeds, Auto Mode) and allows 
intuitive and easy control updates (display layers and wind flight level), and data recording (e.g., 
ATC Approved and ATC Denied). In addition, the Message Window on the middle left hand side 
informs the pilot of general TAP messages (e.g., “Standing by for 10,000 ft.”, “Updating Wind 
Data”, “Updating Active Route”), Auto Mode messages (e.g., “Processing”, “Monitoring for 
Optimal Solutions”, “No Predictions - Initial Turn Too Large”), and Manual Mode messages (e.g., 
“Ready to Create Route”, “Clear”, “SUA” / “Wx” / “Traffic” constraints / hazards impacting the 
candidate route, “Add Rejoin WPT”, “Unable to Rejoin Route at {waypoint name}”, “No 
Predictions - {waypoint name} Not Recognized”, “No Predictions - Excessive Turn at {waypoint 
name}”). 
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Figure 8 TAP HMI V2 Selected Optimization Screen of the Auto Mode 

The V4 Auto Mode Sereen effeetively integrates two of the V2 Auto Mode Screens into a single 
display screen. V4 Auto Mode makes better use of the display area by effectively using display 
space without excessive information density, careful intuitive layout, and using color effects, 
shading and raised, 3D depth on tabs and display fields. Using these techniques, the V4 Auto Mode 
Screen combines both the V2 Auto Mode Screen (Figure 7) and the V2 Selected Optimization 
Screen (Figure 8) into a single V4 Auto Mode Screen, while also including Top Bar and Bottom 
Bar Controls and the Message Window (Figure 9). 

From Figure 9, the Solutions Panel in the upper left portion of the V4 Auto Mode Screen 
effectively integrates the entirety of the V2 Solutions and Outcomes Panels. The V2 Auto Mode 
Screen - Controls Panel portion is also integrated into the lower left portion of the V4 Auto Mode 
Screen. In addition, the V2 Selected Optimization Screen from V2 is integrated into the right hand 
side of the V4 Auto Mode Screen as the Visualization Panel. 

Figure 9 illustrates highlighting of the best solution using a green border that outlines the solution 
field (waypoints and outcomes). In addition Figure 9 illustrates the graphical depiction of the 
Preview Solution, from the Solutions Panel (upper left), into the Visualization Panel (right hand 
side); the double horizontal parallel lines, highlighted in lighter blue color, tie the textual Solution 
and Outcome to the graphically displayed Preview Solution (Cyan) in relation to the FMS active 
route (Magenta). 

The V4 Auto Mode Visualization Panel provides much improved graphical depiction of route 
information providing scale and orientation and also provides zoom in / out and step capability for 
viewing the active and preview routes. 

When using the Auto Mode, TAP only identifies and provides flight trajectory / route improvement 
candidates to the pilot that are clear of hazards / conflicts (e.g., traffic, weather, SUA). In the rare 
case that a hazard / conflict would be present and be observed by TAP and yet TAP offers the route 
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as a candidate solution, the hazard would be indicated in the Message Window and also in the 
graphical route depleted in the Visualization Panel. 
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Figure 9 TAP HMI V4 Auto Mode Screen 


As indieated above, presenee of a hazard / eonflict should not occur for solution candid- 
ates offered by TAP when operating in the Auto Mode. In the event of this unplanned, 
rare oecurrence, display of the hazard in the Message Window and Visualization Panel 
serves to mitigate any adverse effeets of potentially misleading information. 

Unlike Auto Mode, when the pilot utilizes the TAP Manual Mode to explore potential 
trajeetory route improvement opportunities, TAP will evaluate the pilot’s route input 
for potential fuel and/or flight time savings, but in addition, will also evaluate the ean- 
didate route for potential hazards. When hazards are present that impaet the desired 
route, this will be indieated in the Manual Mode Sereen Message Window and also its 
Visualization Panel. The Manual Mode HMI is described below in the next seetion. 

The deseription and eomparison of the TAP HMI V2 and V4 provided above are 
relatively high-level and are intended to provide sufficient overview and insight into 
the TAP HMI design to allow identification of any issues that may affect certification 
of the TAP HMI for use as a fiight-deek application. Additional details on the speeifie 
use of the TAP HMI (e.g., eontrols, status indications, use of drop-down and pop-up 
menus for seleetion purposes, and keyboard entries for input and editing) were derived 
from the respeetive pilot training presentations (in the form of PowerPoint slides and 
graphies) that were provided as training inputs to the pilots that participated in the two 
HITL experiments [32] for HMI V2 and [33] for HMI V4. 
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4.2. 5. 3. 2. 3 Manual Mode Screens 


Figure 10 and Figure 1 1 illustrate the TAP FIMI V2 and V4 Manual Mode Screens, respectively. 

4.2. 5. 3. 2. 3.1 V2 Manual Mode Screens 

The TAP HMI V2 Manual Mode Screen (Figure 10) is relatively basic in its use, providing the 
pilot a textual means to edit the active route to explore trajectory change candidates for fuel and / 
or time savings. The pilot must first specify the desired Reconnect Waypoint to which TAP will 
evaluate the proposed trajectory change. A pop-up window (not shown) lists the waypoints 
associated with the active route from which the pilot selects the Reconnect Waypoint. The pilot 
then selects 0, 1, or 2 off-route waypoints in creating the route that he or she wants to have TAP 
evaluate that can either be entered via keyboard or using the Find WPT tool for waypoint search. 
The pilot can also provide the desired flight-level change if he or she wants to evaluate a new flight 
level over the active route. At this pilot can choose to submit the entered route for evaluation by 
TAP. 

Figure 1 1 illustrates the results of an example evaluation of a manual-mode entered route by the 
pilot. While the example provided is not reflective of a good selection, it serves to demonstrate the 
outcome of the solution in terms of fuel and time impact compared to the current active route, 
while also indicating that the route under evaluation is impacted by both traffic and weather 
hazards / constraints and should thus not be requested from ATC. 

4.2. 5. 3. 2. 3. 2 V4 Manual Mode Screen 

As was the case for Auto Mode, the TAP HMI V2 Manual Mode Screen has undergone 
considerable revision for the TAP HMI V4 Manual Mode Screen (see Figure 12). From Figure 12, 
the V4 Manual Mode Screen consists of three panels: 1) the Entry Tools Panel in the upper left, 2) 
the Visualization Panel on the right half side, and 3) the Route Tray Panel in the lower left of the 
Manual Mode Screen. The Manual Mode Screen utilizes additional Top Bar and Bottom Bar status 
and control elements that increase pilot awareness of TAP operation (Cruise settings. Data Feeds, 
Auto Mode) and allows intuitive and easy control updates ((display layers and wind flight level), 
and data recording (e.g., ATC Approved and ATC Denied). 

The TAP HMI V4 maintains overall compatibility between Auto Mode and Manual Mode Screens, 
with the notable exception relating to the fact that Manual Mode involves pilot entry of route 
information via the Entry Tools Panel and output of route evaluation results from TAP via the 
Route Tray Panel; otherwise the Auto and Manual Mode Screens are very consistent in their use 
and in their display representations for V4. 

In the V4 Manual Mode Screen, the pilot utilizes the Entry Tools Panel (upper left in Eigure 12) 
to select flight level (EL) changes if desired, can add 1 or 2 waypoints via the Add WPT tab and 
also provides the rejoin waypoint via the Rejoin WPT to enter the route for evaluation by TAP. 
The Route Tray (lower left in Eigure 12) allows textual display of the Message Window, 
identifying status and potential hazards (e.g.. Traffic, Weather), and providing estimated effect of 
the proposed route on fuel and /or flight time in the Outcome Window. 

Eigures 13, 14, and 15 provide several illustrations of the V4 Manual Mode Screen, with emphasis 
on the use of the Visualization Screen (right half of display area) using Preview Route, traffic 
hazard, and weather hazard depictions, respectively. 
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Figure 10 TAP HMI V2 Manual Mode Screen 
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Figure 11 TAP HMI V2 Manual Mode Screen with Evaluation Results 
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Figure 12 TAP HMI V4 Manual Mode Screen 

Figure 1 3 illustrates the results of a manual route entered by the pilot using two off-route waypoints 
(NEWA and NEWB), rejoining the Active Route at NEXTE. Heading and distance are indicated 
to the next waypoint. The Route Tray provides depiction of the waypoints and indicates that they 
are free of hazards and indicated by the green simulated light-emitting diodes (LEDs). Also shown 
are the anticipated outcome for fuel and time savings. 

Eigure 14 illustrates the V4 Manual Mode Screen for the scenario where a traffic hazard is im- 
pacting the pilot-entered route. This does not necessarily indicate that the aircraft would be on an 
immediate collision course, however. It indicates only that traffic is in the vicinity with separation 
loss being a possibility (TAP uses a significant buffer on the minimum separation criteria). As 
noted in the dialog boxes in Eigure 14 (not part of the actual TAP display symbology, but to help 
highlight the display elements), the traffic is depicted in the Visualization Panel by a white line 
that represents the current track, flight level, and vertical trend (in this case traffic is climbing). 
Also shown is the general portion of the pilot-entered route being impacted via the dashed yellow 
line terminating at the NEXTC waypoint, representing the portion of the route affected by the 
traffic hazard. This depiction of traffic intentionally does not show the actual or predicted location 
of traffic at any point in time, but is only intended to provide situational awareness to the pilot that 
traffic is in the vicinity and the general impact to the Preview Route that the pilot is considering 
for evaluation by TAP (direct to NEXTC in this case). 

The Route Tray includes the Message Window which provides the textual indication of “Traffic” 
highlighted in yellow indicating the existence of the hazard; also contained in the Route Tray is 
the textual waypoint name impacted by the traffic hazard, i.e., NEXTC, with the status LED 
activated in yellow. 

Eigure 15 illustrates the V4 Manual Mode Screen for the scenario where a weather hazard is in the 
vicinity of the current route. The weather hazard is shown in the form of a polygon (shown in 
white); the yellow dashed line indicates the orientation and general direction and distance of the 
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weather hazard from the approximate location of own ship to the impacted waypoint along the 
current route (in this case NEXTE). This graphical depiction of the weather hazard provides the 
pilot with situational awareness and also allows the pilot to potentially request a candidate route 
using the manual mode for evaluation by TAP. 

The Route Tray includes the Message Window which provides the textual indication of “Weather” 
highlighted in yellow indicating the existence of the hazard; also contained in the Route Tray is 
the textual waypoint name that would be impacted by the weather hazard, i.e., NEXTE, with the 
status LED turned yellow. 
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Figure 13 TAP HMI V4 Manual Mode Screen - Preview Route Depiction 

This section has attempted to provide an overview of TAP HMI V2 and V4, with emphasis on V4. 
V4 currently represents the most mature HMI interface developed by NASA for the TASAR EEB 
application and incorporates pilot feedback from HITL-1 [32], the initial flight trial of TASAR 
[8], and other pilot engagements. TAP HMI V4 has undergone assessment in a second HITE 
evaluation (HITL-2) at the University of Iowa OPE. The data of HITL-2 is currently being 
analyzed. 

Additional details of TAP HMI V4 are not covered in detail in this document as they are not viewed 
to impact certification of the TAP HMI. A more comprehensive description of TAP HMI V2 and 
V4 can be found on the respective pilot training presentations that were provided to pilots for the 
two HITE experiments [32] [33]. 
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Figure 14 TAP HMI V4 Manual Mode Screen - Traffic Hazard Depiction 
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Figure 15 TAP HMI V4 Manual Mode Screen - Weather Hazard Depiction 
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4.2.5A 


Certification Assessment ofTAPHMI V4 

Thus far in this report it has been noted that TASAR is a “Minor Effeet” Class 2 EFB Type B 
applieation, with supporting rationale summarized in Seetion 2 and Appendiees A and B. Also 
noted is a list of references provided of pertinent of FAA regulatory, certification, and operational 
approval requirements that were cited as part of prior certification and operational approval 
requirements assessment. Included in this assessment was the TAP HMI V2. Additionally, Section 
2.3 provided an update to changes to the cornerstone Advisory Circular (AC) 120-76C that could 
potentially affect TASAR certification. 

Section 3 described both TAP HMI V2 and V4 and identifies pilot comments and feedback that 
led to many of the enhancements to the TAP HMI that are incorporated in TAP HMI V4. 

4.2. 5.4.1 Certification Assessment of TAP HMI V4 Usability Features - General 

Many of the enhancements made resulting in TAP HMI V4 directly address the ease of use and 
understanding of the TAP HMI as noted by the pilots in HITE simulation evaluation [32] and 
during actual operational flight evaluation of TASAR [8]. In addition, the majority of 
enhancements in V4 address the checklist factors that the operator needs to specifically address 
with the POI in the Tabletop EFB Evaluation Checklist #1 [14]. This checklist addresses the 
following that must be satisfactorily answered as part of the HMI design: 

• Revision history and expiration dates to be clearly presented 

• Responsiveness of EFB to inputs 

• EFB processing speed 

• Use of busy / progress indicators 

• Consistent user interface allowing selection and use of functions and navigating the display 

• Display of needed information and ease of access (avoid missing or difficult to find 
information) 

• Common actions and timely access to critical functions 

• Standard ways to perform common actions 

• Uniformity of display and controls across the application and also other applications 

• Color viewing and ability to distinguish in various lighting conditions 

• Color coding / shading / highlighting for display of critical information 

• Appropriate use of red and yellow colors (only use for warnings and cautions) 

• Readability of text (including in low-visibility conditions) 

• Contrast of text in relation to display background 

• Use of upper and lower case frequency 

• Ease of bringing out of view information into view 

• Icon and symbol functions obvious and distinguishable/explained by label or other means 

• Ability to quickly and accurately find information 

• Consistency of information layout 

• Ease of being able to read high-priority information 

• Easy to determine open/active application(s) 

• Detection of incorrect information formats / data range, and error messages 
Note: The detailed Checklist 1 questionnaire is provided in Appendix D (D.l). 
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TAP HMI V4 includes many updates and enhancements that are responsive to the pilot feedback 
from [32] [8] and the above list of Checklist #1 Questionnaire used for POI review and approval 
[14], While these are expected to significantly improve the TASAR EFB application, they are in 
themselves not critical with respect to having an adverse effect on to the TASAR FEC of “Minor 
Effect” that has already been established in our discussions with FAA approval authorities. The 
aggregate of changes made for the TAP HMI V4 from the list of items above all serve to improve 
the usability of the TAP HMI, but they do not raise any certification issues that impact the TASAR 
“Minor Effect” FEC. However, the updates to the TAP HMI V4 Visualization Panel as described 
in Section 3. 2. 3. 2 were significant and require closer scrutiny with respect to potential certification 
impact to TASAR. The certification ramifications of these updates to V4 are discussed next. 

TAP HMI V4 enhancements to the Visualization Panel, particularly for Manual Mode, but also 
potentially a factor in the Auto Mode are 1) the graphical depiction of traffic hazards (Figure 14), 
2) graphical depiction of weather hazards (Figure 15), and 3) the implicit approximate location of 
own ship that can be inferred from the Visualization Panel, i.e., with own ship generally located 
near the bottom center of the Visualization Panel. 

Note: While the pilot’s use of the Manual Mode to evaluate route improvement candidates may 
result in hazards being identified by TAP (e.g., traffic, weather, SEIA), in rare cases, the 
Auto Mode may also result in the identification of hazards. In the Auto Mode, TAP 
processing is designed and intended to inhibit any hazard-impacted solutions being offered 
to the pilot via the TAP HMI, and thus should not contain hazard impacted route 
candidates. However, in the event of an unanticipated processing failure, a spurious hazard 
could potentially be displayed in the Auto Mode. The same certification assessment of the 
graphical depiction of hazards on the V4 Visualization can be applied to both Manual and 
Auto Modes. 

Note: While not explicitly shown and considered in Section 3.2 in the description of the TAP 
HMI, indication of an active SUA region on the Visualization Panel, while not a hazard, 
represents an area that the aircraft must not enter, and can be treated similar to a weather 
hazard region. This is discussed further below. 

4.2. 5.4.2 Certification Considerations for TAP Depiction of Traffic Hazards 

As discussed in Section 2.3 (from AC 120-76C [13]), applications supporting communications, 
navigation, and surveillance are viewed as “non-EFB” software applications by FAA, requiring 
Type C, certified software, and certified hardware platforms, e.g., avionics. For TASAR, the 
display of traffic information must be carefully considered to avoid crossing into the surveillance 
functions domain or equivalently into CDTI-based applications. Pilot feedback indicated a desire 
to be provided with the “what” and the “why” in using TAP, requesting to be shown the 
information concerning the potential hazards, e.g., traffic, that may arise in using the TAP Manual 
Mode. 

The TAP HMI V4 was carefully designed by NASA to provide an indication of traffic hazards, as 
shown in Figure 14, by providing a sufficient level of traffic awareness, without showing precise, 
actual traffic location and speed information. In doing so, TAP does not encroach on explicitly 
displaying surveillance / CDTI-based information that may be (mis)used by the pilot for 
operational guidance, maneuvering, and control, but does serve to provide the situational 
awareness that the pilots have requested in their use and evaluation of the TAP HMI. 
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The TAP HMI V4 display of traffic hazard information does not raise any additional certification 
issues commensurate with the TASAR “Minor Effect” EEC. Even in the event that the traffic 
information is erroneously displayed on the TAP display, while undesirable, this does not 
adversely affect the safety of operations, as significant mitigations are in place in using the TASAR 
application. Section 4.6 reiterates some of the major mitigations that support the TASAR “Minor 
Effect” EEC. 

4.2. 5.4.3 Certification Considerations for TAP Depiction of Weather Hazards 

AC 120-76C [13] indicates the following as it relates to the use and display of weather information 
for EEB applications: 

“Section ll.e.4.c [13] notes that “data link EEB functions may display approved sources of 
weather for strategic / flight planning purposes”. Section ll.e.4.d [13] notes that “data link 
graphical weather from approved sources of advisory weather information can only be used 
for strategic / flight planning purposes”. “Do not use data link graphical weather information 
for tactical decisions during critical phases of flight, because data quality is uncontrolled for 
aviation use. Do not use data link graphical weather data as a substitute for airborne weather 
radar or thunderstorm detection equipment.” 

Note 1: Pertaining to ^"approved sources of weather". Air carriers and operators certificated 
under the provisions of 14 CER Part 119 are required to use the aeronautical weather 
information systems defined in the Operations Specifications issued to that certificate 
holder by the EAA. These systems may utilize basic EAA/National Weather Service 
(NWS) weather services, contractor or operator-proprietary weather services and/or 
Enhanced Weather Information System (EWINS) when approved in the Operations 
Specifications. As an integral part of this system approval, the procedures for collecting, 
producing and disseminating aeronautical weather information, as well as the crew 
member and dispatcher training to support the use of system weather products, must be 
accepted or approved. 

Note 2: The EAA has identified three distinct types of weather information available to pilots and 
operators: 

1) Observations - Raw weather data collected by some type of sensor suite including 
surface and airborne observations, radar, lightning, satellite imagery, and profilers. 

2) Analysis - Enhanced depiction and/or interpretation of observed weather data. 

3) Forecasts - Predictions of the development and/or movement of weather phenomena 
based on meteorological observations and various mathematical models. 

Not all sources of aviation weather information are able to provide all three types of 
weather information. The EAA has determined that operators and pilots may utilize the 
following approved sources of aviation weather information: 

1) Federal Government - The EAA and National Weather Service (NWS) collect 
raw weather data, analyze the observations, and produce forecasts. The EAA and 
NWS disseminate meteorological observations, analyses, and forecasts through a 
variety of systems. In addition, the Eederal Government is the only approval 
authority for sources of weather observations; for example, contract towers and 
airport operators may be approved by the Federal Government to provide weather 
observations 
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2) Enhanced Weather Information System (EWINS) - An EWINS is an FAA 
authorized, proprietary system for traeking, evaluating, reporting, and foreeasting 
the presenee or laek of adverse weather phenomena. The FAA authorizes a 
eertificate holder to use an EWINS to produce flight movement forecasts, adverse 
weather phenomena forecasts, and other meteorological advisories. For more 
detailed information regarding EWINS, see the Aviation Weather Services 
Advisory Circular 00-45 and the Flight Standards Information Management System 
8900.1. 

3) Commercial Weather Information Providers - In general, commercial providers 
produce proprietary weather products based on NWS/FAA products with 
formatting and layout modifications but no material changes to the weather 
information itself This is also referred to as "repackaging." In addition, commercial 
providers may produce analyses, forecasts, and other proprietary weather products 
that substantially alter the information contained in government-produced products. 
However, those proprietary weather products that substantially alter government- 
produced weather products or information, may only be approved for use by 14 
CFR Part 121 and Part 135 certificate holders if the commercial provider is EWINS 
qualified. Commercial weather information providers contracted by FAA to 
provide weather observations, analyses, and forecasts (e.g., contract towers) are 
included in the Federal Government category of approved sources by virtue of 
maintaining required technical and quality assurance standards under Federal 
Government oversight. 

Pilot feedback indicated a desire to be provided with the “what” and the “why” in using TAP, 
requesting to be shown the information concerning the potential hazards that may arise in using 
TAP, e.g., weather hazards and their location. The TAP HMI V4 Visualization Panel provides 
depiction of weather hazard polygons and their location relative to the active and preview routes 
(Figure 15). 

The TAP HMI V4 display of weather hazard information does not raise any additional certification 
issues commensurate with the TASAR “Minor Effect” FEC, as pilots, supported by proper 
training, are only allowed to utilize this information as part of strategic / flight planning and for 
situational awareness purposes. They must utilize the out-the-window scan, weather radar and/or 
thunderstorm detection equipment to make any tactical decisions during critical phases of flight. 

Even in the event that weather information displayed erroneously on the TAP display, while un- 
desirable, this does not adversely affect the safety of operations as the pilot must utilize their 
weather radar and/or thunderstorm detection equipment for tactical decision making of the flight. 

4.2. 5.4.4 Certification Considerations for TAP Implicit Use of Own Ship 

FAA AC 120-76B [34] was strict in its view of depiction of own ship on the EFB display, forcing 
a “Major Effect” designation if own ship was displayed. FAA AC 120-76C [13] relaxes this 
requirement somewhat by allowing display of own ship in certain cases. Reference [13] allows the 
display of own ship on the EFB display when the aircraft is operating on the airport surface at 
speeds less than 80 kn ots. However, [13] continues to maintain that display of own ship in flight 
(or on the surface at 80 knots or greater) will result in a “Major Effect” FEC, requiring the 
corresponding increase in software certification and operational approval requirements, e.g., 
requiring approved software per DO-178B. 
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From a TASAR application perspective, the TAP HMI must not display own ship position on the 
EFB display, as the TASAR intended function is strictly as an en route advisory tool for the pilot 
and cannot support surveillance functions. TAP HMI V4 does not explicitly depict own ship on 
the Visualization Panel, but implicitly assumes that own ship is generally in the near vicinity of 
the bottom center of the Visualization Panel (refer to Figure 14 or 15). 

Note: AC 120-76 Appendix 2 [13] allows for Type B applications that utilize precomposed or 
dynamic interactive eleetronic aeronautieal eharts (e.g., en route, area and approach, and 
airport surface maps) including, but not limited to, centering and page turning, but without 
display of airborne aircraft/own-ship position. This is similar to the TAP Visualization 
Panel depleting traffie and weather hazards without explicitly depicting own ship position. 

4.2. 4.4.5 Certification Considerations for TAP Depiction of Special Use Airspace 

As with traffic and weather hazards, pilots do want to have situational awareness of SUA areas for 
display on the TAP HMI. Unlikely weather, SUAs are not necessarily hazards, but they represent 
areas that must be cireumvented by flights. Flight plans and vectors from ATC ensure that aircraft 
successfully avoid SUA when they are active. TAP provides situational awareness to the pilot for 
SUA(s) in the form of polygon shapes and locates them in the proper location and orientation 
relative to the aetive and preview routes. In the event of misleading information that may result in 
improper or missing depletions of SUAs on the TAP HMI, while undesirable, sufficient 
mitigations are in place to mitigate any safety effects. Proper training to follow the actual flight 
plan via the FMS, ATC clearances, and ATC monitoring of flight progress will prevent inadvertent 
entry into an active SUA. 

4.2. 5.4.6 Usability Considerations; TASAR Mitigations 

With the TASAR application having a “Minor Effect” EEC, associated information sources must 
be of comparable quality (accuracy, timeliness, and integrity) to maintain the probability of 
missing and undetected misleading information in line with the “Minor Effecf’ designation. 
Information quality is not a safety issue for TASAR, but a usability issue. In order for the TASAR 
application to be accepted by pilots, it must be sufficiently available, consistent, and predictable 
in its advisory role to not create undue confusion and unnecessary workload; otherwise, the pilots 
will not utilize TASAR for its intended role of assisting the pilot to determine route improvement 
opportunities. 

TASAR has a number of strong mitigations, both internal and external to the application, and is 
also supported by procedures that ensure safety. Reference [7] provides a comprehensive list of 
TASAR mitigations that support the “Minor Effect” FEC. Several of these mitigations are listed 
below: 

• The pilot has responsibility to evaluate TASAR-provided trajectory change request 
candidates before making a change request to ATC, providing eross-check opportunities 
to detect spurious or false trajectory change request candidates offered by TASAR 

• Pilot crosschecks of aircraft systems, e.g., EMS, weather radar, which serve as available, 
higher integrity information allowing quiek check on acceptability and performance 
impacts of TASAR recommended change requests 

• ATC provides separation assurance independent of TASAR 
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• Aircraft safety systems (e.g., Traffie Alert Collision Avoidanee System {TCAS}, airborne 
Weather Radar {WxR}, and Terrain Awareness Warning System {TAWS}) provide 
hazard detection and alerting 

• ATC monitors exeeution and intereedes 

• Pilot Training 

4.2. 5. 5 TAP V4 Certification Assessment - Conclusions 

After eareful review of the TAP HMI V4 improvements made by NASA in response to pilot 
feedback from the HITL-1 simulation evaluation [32], flight evaluation in an operational 
environment [8], and through pilot diseussion forums, and review of the latest FAA guidanee 
doeuments, e.g., AC 120-76C [13], this analysis eoneludes that the TASAR “Minor Effeet” EEC 
is unaffeeted by the updates provided in V4. TAP HMI V4 is eurrently undergoing further 
evaluation and analysis in another HITE simulation experiment and in planned flight trial 
evaluations. It is antieipated that V4 improvements will eontinue to demonstrate that the TASAR 
applieation is 1) useful, understandable, and intuitive to operate, 2) provides situational awareness 
without adversely affeeting workload, 3) does not interfere with the primary flight duties on the 
flight deek during nominal and off-nominal eonditions, and 4) fits in nieely with flight deek 
operations, i.e., is a weleomed advisory tool that provides operational benefits of fuel and/or time 
savings. TAP HMI V4 has made many enhaneements over initial TAP HMIs, addressing numerous 
pilot reeommendations and is expeeted to bring NASA eloser to eventual teehnology transition of 
TASAR as a flight-deck application. 

4.3 FAA Certification and Operational Approval Technical Interchange 
Meeting 

NASA and Rockwell Collins TASAR Prineipal Investigators met with key FAA deeision makers 
regarding certifieation and operational approval for the NASA TASAR EFB application. A 
technical interchange meeting was held at FAA offiees in Washington DC on July 24, 2013 with 
key FAA approvers of EFB and ADS-B avionies systems present, and with NASA Langley and 
Roekwell Collins partieipants. The meeting was seheduled for two hours duration; additional time 
was spent in dialog and demonstration of the TASAR EFB prototype. This seetion provides a 
summary of results from these discussions and notes any significant difference based on FAA 
feedbaek as eompared to our original analyses. 

In general it was eonfirmed by FAA that the results of our safety analyses and our analyses 
eoneerning eertifieation and operational approval requirements for the TASAR EFB applieation 
were elosely aligned with FAA’s guidanee materials that already exist for TASAR. FAA feedbaek 
reaffirmed that we had analyzed the requirements correctly as applicable to TASAR. 

Due to the “Minor Effeef ’ FEC for TASAR as a Type B applieation, hosted on a Class 2 EFB, and 
the fact that existing FAA polieies already fully cover the proposed TASAR EFB application, FAA 
noted that the full formalism of a Projeet Speeifie Certifieation Plan (PSCP) described in detail in 
this doeument will likely not be required. FAA noted that applieants ean direetly engage with the 
POI for operational approval of TASAR as eurrently defined, partieularly in regard to the EFB 
mount and hardware installation. 
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The following is a meeting summary along with feedback, key discussion points, and observations 
based on the discussions held with the FAA. More detailed feedback from this meeting is found in 
Appendix E. 

Meeting Highlights 

FAA certification (AIR) and operational approval (AES) personnel with approval authority for 
fielding of EFB applications and ADS-B avionics (IN and OUT) and representatives from the 
NASA TASAR team held a technical interchange meeting at FAA offices at E ’Enfant Plaza on 
July 24, 2013. This meeting went very well from the NASA TASAR team’s perspective and met 
and exceeded expectations. The meeting in essence served as validation of information that was 
provided concerning future approval requirements for TASAR, per the current application 
description and concept of use [3]. Presentations provided by NASA (David Wing, the TASAR 
Principal Investigator) and Rockwell Collins (Steve Koczo, analyst of TASAR Certification and 
Operational Approval Requirements) provided an introduction to the TASAR concept, a 
comprehensive, integrated presentation of TASAR safety analyses, and assessments of 
certification and operational requirements as documented throughout this report. These 
presentations were provided to FAA prior to the meeting, and it was apparent that members of the 
FAA team took advantage to review this information going into the meeting. Per FAA, we had 
succeeded in assembling the “right team” of approvers for TASAR technologies. FAA participants 
were actively engaged throughout the 2.5 hour meeting and offered additional insight. An FAA 
representative noted that the meeting was in essence a “trial run” for how to conduct a meeting 
with FAA for certification and operational approval. 

The key result of the meeting is confirmation that existing policies already cover the proposed the 
TASAR application and we had correctly reviewed and analyzed FAA regulatory and guidance 
documents applicable for EFB applications such as TASAR. The following list summarizes 
feedback from FAA both confirming and helping to clarify some of our analysis results: 

• TASAR is a Type B application and is appropriately hosted on a Class 2 EFB 

• TASAR does not need to be added explicitly to the list of Type B applications in Appendix 
2 of AC 120-76C [13] 

• Type B applications running on non-certified hardware (e.g.. Class 2 EFB) do not require 
DO-178B compliance 

• TASAR will be viewed as a “Minor Effect” application due to potential pilot workload 
associated with TASAR due to misleading / bad data. From a loss-of-function standpoint, 
TASAR is viewed as “No Effecf ’ 

• TASAR is not an ADS-B IN applications, but rather a performance/planning application 
that leverages ADS-B IN data, if available 

• There is not a need to establish a separate standard for TASAR, allowing freedom for users 
to implement the application to fit their individual needs 

• If an operator already has an existing EFB installation, then the operational approval 
process is for the user to go directly to the POL 

For detailed feedback and discussion items from the FAA meeting refer to Appendix E. 
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Appendix A TASAR User Survey Results, Findings and Recommendations 

This appendix provides the detailed results of the analysis of TASAR survey results conducted by 
Rockwell Collins. Analysis results are provided and organized as follows: 

• A. 1 examines current and planned systems that play a role in enabling early deployment of 
TASAR for the end user operator; operator equipage plans are considered for the possibility of 
early adoption of TASAR. 

• A.2 presents an overview of the operations and demographics of the operators surveyed. 

• A. 3 examines survey responses related to challenges and disruptions to flight operations. 

• A.4 reviews the change request process in requesting a revised clearance from ATC. 

• A. 5 examines tools used by pilots and dispatchers in flight planning and in-flight re-planning 
while en route. 

• A. 6 discusses information sources, including their effectiveness (or lack thereof) in current 
Dispatch and flight operations. 

• A. 7 identifies organizational policies, constraints, and cost factors associated with flight 
planning processes as obtained from survey responses. 

• A. 8 summarizes the survey results, observations and recommendations obtained from the 
analysis of the TASAR User Survey for early adoption of TASAR. 

Note: The survey questions and corresponding responses were in many instances qualitative and 
subjective in nature. In addition, the responses represent only a small sample and thus 
cannot be used to make fundamental conclusions and extrapolations. However, the three 
operators represented in the survey and the comprehensive questions and responses from 
the various stakeholders involved in flight planning and flight execution do allow 
reasonable conclusions to be drawn that were used to inform the TASAR research team in 
developing updates to the TASAR application. 

A.l Current & Planned Systems Supporting Potential Deployment of TASAR 

Figure A-1 provides a functional diagram of TASAR. The TASAR software, also known by the 
name “Traffic Aware Planner,” is hosted on the EFB and is enabled by information from own ship 
and via information derived via the internet and data link. Own ship data is provided via ARINC 
429 Busses from on-board systems, including the Flight Management System (FMS) and the 
Traffic Computer (the platform for ADS-B IN). These data are provided to the Aircraft Interface 
Device (i.e.. Data Concentrator) for input to the EFB using the Single Text Avionics Protocol 
(STAP) interface. The User Survey probed for operator equipage (current and planned) for systems 
needed to support TASAR. Before explicitly examining the equipage results from the User Survey, 
the results of a meeting of the NASA TASAR team with FAA certification and operational 
approvers for EFB and ADS-B IN systems are noted below, as the results of this meeting 
reinforced our assessments of the level of requirements that need to be met in order to gain 
approval for operational use of TASAR. 

The TASAR User Survey requested inputs from three operators (a Global Network Carrier, 
Domestic Low-Cost Airline Carrier, and a Eractional Operator of Business Aircraft) on their 
equipage plans for the following capabilities: 
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Figure A-1 TASAR Functional Diagram 

1) ADS-B OUT (1090 MHz or UAT) 

2) ADS-B IN (1090 MHz and/or UAT) - referred to as the Traffie Computer in Figure A-1 . 

3) EFB Class (1,2 or 3) 

4) EFB Operating System (Windows, Einux, iOS) 

5) Internet aeeess (terrestrial network, satellite network) 

6) Data Comms (ACARS, CPDLC) 

Survey results were reviewed for eaeh eapability and for eaeh operator. 

Note: Survey results were reeeived during 2013; future plans and results of levels of equipage of 
the surveyed operators are subjeet to regulatory and market forees. The information below 
represents operator equipage and plans as of 20 1 3 and refleet differenees between operators 
and their respeetive markets. 

A.1.1 ADS-B OUT 

The Global Network Carrier surveyed is well on the path to equip toward the 2020 mandate of full 
ADS-B OUT equipage and tends to have relatively higher level of equipage already in place (40%), 
likely due their global operations footprint where ADS-B OUT is used more frequently (e.g., in 
Europe, Australia). While not explicitly stated, this operator will be 1090 MHz ADS-B as their 
entire fleet is Air Transport category aircraft, which will be 1090 MHz equipped per the ADS-B 
mandate. 

The Low-Cost Airline surveyed is also working toward the 2020 mandate, but is less aggressive 
in equipping its fleet compared to the Global Network Carrier. While not explicitly stated, this 
carrier will be 1090 MHz ADS-B as their entire fleet consists of Air Transport category aircraft, 
which will be 1090 MHz equipped per the ADS-B mandate. 

The Eractional Operator surveyed is currently not working toward the ADS-B OUT mandate, even 
indicating uncertainty for the 2020 mandate date. While unlikely, it is possible that some of their 
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aircraft could equip with UAT for ADS-B (for those operating below 18,000 ft.), but in all 
likelihood, this operator will also need to equip with 1090 MHz ADS-B. 

General observations: 

• Currently anticipated ADS-B OUT equipage levels for the three operators in the survey suggest 
a relatively slow deployment, resulting in a signifieant number of aireraft being unequipped, 
i.e., a mixed-equipage environment is expeeted all the way to the 2020 mandate. 

• Aircraft not equipped with ADS-B OUT will eonsequently not be equipping with ADS-B IN, 
and thus these unequipped aireraft will not benefit from the ‘traffie aware’ benefits of TASAR. 
However, TASAR ean be installed without “traffie awareness” if the business ease warrants 
such an investment to equip. 

Note: All aireraft must have ADS-B OUT (with a few minor exeeptions for aireraft that do not 
have electrieal systems when eertified and a few other minor exeeptions). All aireraft 
operating above 18,000 feet must utilize 1090 MHz ADS-B OUT. 

A.1.2 ADS-B IN 

Based on the survey responses. Global Network Carrier eurrently is not planning on ADS-B IN in 
the near-term and no clear deeision have been made for 2020 equipage at this time. 

The Low-Cost Airline is indieating intent to equip with ADS-B IN at levels eomparable to their 
ADS-B OUT equipage plans, whieh is relatively slow. 

The Fraetional Operator surveyed eurrently does not indieate any plans for ADS-B IN equipage. 
General observation: 

• Without ADS-B IN, TASAR will not be able to benefit from quality ADS-B, TIS-B, and ADS- 
R (rebroadeast) traffie data. TASAR is not reliant on traffie data from ADS-B, as benefits are 
expected to be available without traffic information. However, having access to quality traffic 
information such as provided via ADS-B is highly desirable. 

• With respect to TASAR creating a “pull” for operators to equip with ADS-B IN, this is yet to 
be determined. A strong eost-benefit case would be needed to ereate this “pull.” 

A.1.3 Electronic Flight Bag (EFB) 

The Global Network Carrier at present has 100% equipage of Class 2 EFBs, with some also 
equipped with Class 1 . The survey response suggests that 2020 equipage plans for the class of EFB 
are not yet determined. This operator has no plans for Class 3 EFBs. 

The Eow-Cost Airline surveyed has 100% Class 2 EFB equipage but will move to 100% Class 3 
EFBs in two years and beyond. 

The Fraetional Operator has 100% Class 1 EFB equipage today and plans to maintain it for the 
future (to 2020). This operator also indicates that ~50% of its aircraft are eurrently equipped with 
Class 3 EFBs (going to 60% in 2 years). Their 2020 plans for Class 3 EFBs are undeeided at this 
time. 

General observations: 

• The operators have diverse plans for EFB use spanning all Classes of use and also use of 
Operating Systems (mix of Windows, EINUX, and lOS). All users should be able to utilize 
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their EFBs to host TASAR, although Class 1 EFBs will need to interface to an Aircraft Inter- 
face Device and will need to meet Transmit-PED (Portable Electronic Device) EMI/HIRF 
requirements for flight deck use). In the event operators integrate TASAR with a Class 3 EFB, 
or equivalently a certified Auxiliary Display System, additional approval steps will be required 
to ensure interoperability of TASAR with other approved software applications. 

• The most direct path for quick and affordable user adoption of TASAR is via a Class 2 EFB 
installation with TASAR as a Type B application. The operators are generally well on their 
way to have this capability that would support early adoption of TASAR. 

A. 1.4 Data Connectivity 

The Global Network Carrier, according to their survey response, has limited internet access 
(whether terrestrial or satellite) available, at least for flight deck use. However, they likely can 
have terrestrial internet service via Gogo, as they are offering that to their passengers for cabin 
use. They also are planning to offer increasing levels of satellite internet for international flights 
via Ku-band for cabin use, which could be used by pilots as well. All aircraft of the Global Network 
Carrier are equipped with ACARS and are beginning to be capable of CPDEC (20% now, up to 
30% in 2 years). 

The Low-Cost Airline, as a domestic carrier, is planning on full equipage of terrestrial internet 
service within 2 years (if not already in place). This operator also has full ACARS equipage and 
will begin to equip with CPDEC (20% in 2 years, 100% by 2020). 

The Fractional Operator, as a business aircraft operator, already has a high-level of terrestrial 
internet equipage (80% today, 90 % in 2 years, 100% by 2020). They have only small amounts of 
ACARS and CPDEC equipage, which are typically used by air transports. 

General observation: 

• The two airline operators are fully equipped with ACARS and are beginning to equip with 
CPDEC (-20% in the near term). The Global Network Carrier has greater CPDEC likely due 
to its Future Air Navigation System (FANS) equipage needed as part of their international 
flight operations. The Fractional Operator, operating business aircraft, generally has limited 
ACARS and CPDEC (-10%), but has widespread terrestrial internet access. The Fractional 
Operator has, and within 2 years the Low-Cost Carrier will have, excellent internet access for 
their operations. The Global Network Carrier appears to be the most challenged in network 
connectivity for future TASAR use but could potentially leverage available cabin internet 
services they provide for passengers to support flight deck applications such as TASAR. 

General observation: 

• Given a favorable cost-benefit business case for TASAR, all three operators could quickly 
equip with full TASAR functionality. Per our analysis of TASAR’ s safety [7], certification and 
operational approval (Sections 4.2.2, 4.2.3, and 4.2.4) and subsequent meeting with FAA 
(Section 4.3 and Appendix E), the path to successfully implementing TASAR is 
straightforward with limited risk toward approval. The non-recurring expense for equipping 
with TASAR functionality is to be determined and would need to be addressed with each 
respective operator. In addition, the cost-benefit assessment likely would need to become more 
mature. The most significant cost item would be ADS-B IN equipage, when compared to the 
cost associated with EFB Class 2 hardware and internet connectivity services. 
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A.2 General Observations on Operator Operations and Demographics 

This section characterizes and makes some initial high-level observations on the respective oper- 
ator operations and their demographics; these will set the stage for more detailed review of User 
Survey results in order to draw conclusions that can help accelerate user adoption of TASAR. 

The operators in the User Survey represent a spectrum from major Global Network Carrier, Low- 
Cost Domestic Airline, and Business Aircraft Fractional Operator. Two operate in primarily 
domestic airspace (i.e., the Low-Cost Airline and the Fractional Operator surveyed). The Global 
Network Carrier surveyed has both major domestic and international operations. 

The two airlines surveyed are Air Transport operators and operate strictly Boeing and Airbus 
transport category aircraft. The Fractional Operator on the other hand operates a wide range of 
business aircraft types as part of their aircraft fleet. 

Seventy percent of Fractional Operator flights are short haul (<2 hours), while -sixty-seven 
percent of the two airline operations are medium to long haul (>2 hours), with forty percent being 
long haul (>4 hours). As a high-level generalization, TASAR provides greatest benefits during the 
en route phase of flight, with benefits diminishing as one transitions to the terminal area, as it 
becomes difficult to affect any flight re-planning at that point during the flight. While TASAR can 
provide benefits during the entire flight regime, the early part of the flight including immediately 
after take-off and climb should still have relatively up to date information on current environmental 
constraints. It is anticipated that TASAR provides the most benefits for medium to long haul 
flights. While all three operators can benefit from TASAR, the longer haul flights of the Global 
Network Carrier and the Low-Cost Airline should be expected to gain additional benefits. 

All Global Network Carrier flights include at least one hub airport as a departing and/or arriving 
airport. 90% of the Low-Cost Airline flights have at least one hub as part of their departing and 
arriving airport. 60% of Fractional Operator do not involve a hub airport. Based on the Global 
Network Carrier and Low-Cost Airline route structures, a greater percentage of hub-to-hub airports 
flights would be expected. Since the Fractional Operator has a majority of its flights operating 
from/to non-hub airports, this removes a significant set of constraint factors related to ATC ground 
stops/holds, metering, etc. Thus while still beneficial, TASAR will not need to deal significantly 
with considering flight re-planning options to deal with ATC constraint factors. Both the Global 
Network Carrier and the Low-Cost Airline will require and benefit from TASAR’ s ability to 
recommend trajectory candidates that help alleviate the severity of ATC constraints. 

General observation: 

• Of the three operators, the Fractional Operator, with its mostly short-haul operations, between 
mostly non-hub airports, has reduced opportunities to take full advantage of operational 
efficiencies offered by TASAR. Benefits are still expected, but their reduced exposure to ATC 
constraints and the shorter duration of flights offer less opportunities to achieve efficiencies. 
The two airline operators on the other hand, with their exposure to ATC constraints at the hub 
airports to which they frequently operate from/to and their generally longer haul flights, offer 
more opportunities to derive TASAR benefits. Additionally, the Fractional Operator’s lack of 
ADS-B IN equipage (at least in their current plans) reduces the “traffic-awareness” capabilities 
offered by TASAR. 

A significant difference exists in the number of pilots, average and peak number of airborne flights, 
and the number of dispatchers utilized by the three operators, ranging from very large numbers for 
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the Global Network Carrier to relatively small numbers for the Low-Cost Airline and the 
Fractional Operator. 

General observations: 

• The Global Network Carrier has very large operations requiring many more dispatchers per 
airborne aircraft compared to the other operators surveyed. The Low-Cost Operator and 
Fractional Operator dispatchers tend to serve many aircraft per dispatcher at one time 
compared to Global Network Carrier. The Global Network Carrier likely must provide a 
greater expanse and diversity of services to support its broad, global operations. In addition, 
The Global Network Carrier’s operational complexities tend to increase Dispatch 
requirements. The Low-Cost Airline and Fractional Operator have simpler route structures and 
scheduling complexity of their operations, with considerably less dependencies on supporting 
connecting flights. These operators require only two to five dispatchers to serve 26 to 100 peak 
aircraft operations (i.e., 10 to 20 aircraft per dispatcher). The Global Network Carrier , with 
aggregate operations support for the worldwide reach of its command center, requires 
approximately one dispatcher for every five airborne aircraft. Surprisingly, per the User 
Survey, the Global Network Carrier’s Dispatch services airborne aircraft primarily when 
requested by the flight crew. 

• The Low-Cost Airline outsources some of it airline operations and supplements its Dispatch 
service using a party optimization service (i.e.. Sabre). The Global Network Carrier and 
Fractional Operator’s Flight Operations are more self-managed. The Fractional Operator’s 
operations control center coordinates with FAA to manage re-routing, weather, ground stops, 
landing slots, etc. 

A.3 Challenges and Disruptive Factors to Flight Operations 

This section analyzes User Survey responses that identify the factors, frequency of occurrence, 
and level of severity to flight operations, specifically disruptive factors affecting the “actual” flight 
as compared to the original flight plan. The survey probed pilots for the frequency of “minimally,” 
“moderately” and “extremely” challenged flights they experienced during the past 12 months. 
Operator perspectives were sought for pilots, dispatcher, and flight operations personnel. 

“Minimally” challenged implies a flight minimally impacted by environmental factors, i.e., devoid 
of convective weather, no occurrence of un-forecast winds, no airspace system disruptions, and no 
adverse traffic influences. 

“Moderately” challenged implies a flight moderately impacted by environmental factors, e.g., 
regional convective weather, non-ideal winds, some airspace system disruptions, and some traffic 
delays. 

“Extremely” challenged implies a flight with highly disrupted operations and severely impacted 
by environmental factors, e.g., widespread delays and diversions caused by weather, very adverse 
winds, airspace system disruptions, major traffic delays, and security events. 

A.3.1 Pilot Perspective 

Pilots indicated that ~2/3 of their flights during are past 12 months were minimally challenged / 
impacted, 25% were moderately; and 10% were extremely impacted. 
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The estimated impact to these flights in terms of additional flight time and additional fuel 
consumption were as follows; 

• 2% time, 1.5% fuel impact for minimally challenged flights 

• 8.7% time, 9.3% fuel impact for moderately challenged flights 

• 17.7% time, 16.15 % fuel for extremely challenged flights 

General observation: 

• About 1/3 of flights are moderately or extremely impacted by adverse environmental factors, 
with ~9% to 17% impact on flight time and fuel impact. This suggests that there is considerable 
opportunity to gain operational efficiencies from decision aids such as TASAR. 

Pilots were asked to characterize the impact of various ATC constraints on operational efficiency 
considering the flights they conducted during the past 12 months. The following ATC factors were 
rated by decreasing level of severity in impacting operational efficiency: 

• Ground holds and ground stops were rated as most severe (5 out of 7, with 7 most severe) 

• Metering or miles-in-trail, also airborne holding are next severe (4.3/4. 1 of 7) 

• Vectoring, speed control, re-routing due to weather are next (~4 of 7) 

• Re-routing of arrival fix, ATC preferred route next (~3.4 of 7) 

• Temporary Flight Restriction (TFR) /SUA (~2.7 of 7) 

General observation: 

• ATC holds and flow management are the primary adverse impacts on flight operations, 
followed by ATC routing. TFRs are not a significant impact. Weather was not mentioned 
excessively as key adverse effect. 

• High quality (timely and accurate) ATC constraint information would strengthen the benefits 
case for TASAR. 

A.3.2 Dispatch Perspective 

This section analyzes the factors that adversely affect the original flight plan and the reasons that 
cause flight re-planning by dispatchers. 

A.3.2. 1 Factors Adversely Affecting the Original Flight Plan (Dispatcher View) 

Given that Dispatch has planned an effective flight plan prior to departure, the following factors 
(in decreasing order of severity) were identified in the User Survey as adversely affecting the 
original flight plan (from the dispatcher’s perspective). 

• ATC metering and flow management (5.33 of 7, with 7 as highest impact) 

• Three weather-related factors 

— En route weather is biggest factor for weather (4.92 of 7) 

— Destination airport weather is 4.42 of 7 
— Departure airport weather is 3.67 of 7 

• Departure delays are less of a factor 

- Due to airport surface (3.75/7) 

- Departure system delays (3+ of 7) 

• Failed on-time pushback from gate (2+ of 7) 
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General observation: 

• TASAR, with good (i.e., pertinent, aeeurate, and timely) information on ATC metering / flow 
management and weather (especially en route and at the destination airport), has the potential 
to provide significant tactical re-planning capabilities for operational efficiency. With TASAR 
the key issue is its usability (i.e., providing benefits while at the same time being streamlined 
with operator dispatch, own ship flight procedures using the FMS, and with ATC’s overall air 
traffic control paradigm {change request clearances, traffic flow management, arrival 
management, etc.}). 

A.3.2.2 Reasons for Flight Re-Planning (Dispatcher View) 

The following factors were rated by dispatchers as the reasons requiring re-planning of the flight 
(in decreasing order of priority): 

• Significant Weather per Dispatch action is #1 reason (33%) 

- Also rated as the #3, 4, 5 reasons with decreasing # of responses 

• Significant Weather per notification from pilot or ATC is #2 reason (41%) 

— Also 4 and 6 with decreasing responses 

• Airspace Disruption (notified by ATC) 

— Broad spread from 2 to 7 

• Aircraft equipment failure 

— Mostly at 6 or 7, but other responses with broad spread from high to low 

• Dispatch initiated to save time, fuel, on-time arrival 

- 3 and 7 (25%) - spread over many priorities 

• Airspace Disruption (monitored and detected by Dispatch) 

- 8 (25%), but broad spread from 2 to 7 (16%, 8%) 

• Fuel Reserve 

• In-flight emergency 

— Priority 8, many small hits across wide level of priorities 

• Security Event 

- 9(66%) 

General observation: 

• From the dispatcher’s perspective. Significant Weather as observed by Dispatch or per 
notification from the pilot or ATC are the primary reasons for re-planning of the flight. 
Airspace disruption notification from ATC follows Weather as the key factors for re-planning. 
The remaining factors are all rated approximately the same, with in-flight emergency and 
security event rated the lowest. 

A.3.3 Flight Operations Perspective 

The following represent survey responses related to disruptive and adverse factors that impact 
flight operations. 

A.3.3.1 Disruptive Flight Factors (Flight Operations View) 

The following disruptive flight factors were identified by operator flight operations: 

• Global Network Carrier view 
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- Airspace disruptions are biggest faetor (6 of 7 with 7 most severe impaet) 

— Traffie Flow Management (TFM) Initiatives and poor foreeast on loeation (5 of 7) 

- To a lesser extent, poor wind foreeast, ieing foreeast, SUA, Notices to Airmen 
(NOTAMS) (2 of 7) 

• Low-Cost Carrier view 

— TFM Initiative is 7 of 7 

- Most others are 3 of 7 (poor wind, poor forecast at location, airspace disruptions) 

— Unexpected SUA/TFR and NOTAMS are 2 of 7 

— Poor ieing foreeast 1 of 7 

• Fractional Operator view 

- Airspaee disruption, TFM Initiatives (5 of 7) 

— Poor wind and foreeast at loeation (4 of 7) 

- king 3 of 7 

- SUA/TFR and NOTAMs 2 of 7 
General observations: 

• TFM Initiatives and Airspace Disruptions were viewed as most disruptive, followed to a lesser 
extent by poor foreeasts On Location and of Winds. Unexpected SUA/TFR, NOTAMS, and 
poor forecast on icing were not viewed to be as disruptive. 

• No strong correlation between responses by operator is noted. 

A.3.3.2 Actual Flight vs. Original Flight Plan (Flight Operations View) 

The survey probed for a high-level assessment of how elosely the aetual flight was able to aehieve 
the original flight plan performanee (in terms of flight time, fuel burned, and on-time arrival) based 
on flights during the last 12 months. 

Actual vs. Original Flight Plan 

• With the exeeption of On-Time Arrival for the Global Network Carrier surveyed (4 of 7, 
meaning mixed results), all responses from all aireraft operators indieate 6 of 7 meeting 
the original plan (flight time, fuel, on-time). 

General observation: 

• Aeeording to the survey results, aetual flights generally met expeetations to original plan, On- 
Time Arrival being an exeeption for the Global Network Carrier. 

A.3.3.3 Adverse Effects on Performance (Flight Operations View) 

The following adverse effeets on flight performanee of aetual flight relative to original flight plan 
were identified: 

• Global Network Carrier 

- Failed on-time pushbaek (7 of 7) 

— Adverse weather at destination (6 of 7) 

- System delays, metering, adverse weather at departure airport (5 of 7) 

- Departure delay on airport surface (4 of 7) 

- Adverse weather en-route (3 of 7) 

• Low-Cost Airline 

— Metering is highest impact (7 of 7) 
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— All others are 3 of 7 or less 

• Fraetional Operator 

- Most are 5 of 7 (departure delay on airport surface, system delays, adverse weather 
at departure airport, adverse weather at destination, metering) 

- Adverse weather en route (4 of 7) 

- Failed on-time at push back (1 of 7) 

General observation: 

• ATC factors seem to have adverse effects at a moderate level (5 of 7). Adverse en route 
weather, while an issue was rated ~4 of 7. Thus TASAR has modest improvement opportunities 
related to ATC factors and a bit less impact on en route weather. 

A.4 Change Requests 

This section closely examines change requests, i.e., the number per flight, type of request, 
coordination with dispatch, and typical ATC response to the change requests. 

A.4.1 Total Number of Change Requests per Flight 

The following are the number of change requests per flight. 

• 1 or 2 per short flights (<2 hours) 

• -equal responses of 1 or 2 and 3 or 4 (for 2-4 hour flight) 

- Averages to 2 to 3, with bias to 2 per flight 

• 3-4 or 5-6 (> 4 hour flight) 

- Averages to 4 to 5, with bias toward 4per flight 

General Observation: 

• Approximately one change request per flight hour regardless of length of flight (short, 
moderate, long haul). 

A.4.2 Type of Change Requests 

Pilots were asked of the type of change requests that are typical. 

• Types of change requests 

- altitude, lateral route (100%) 

- heading (-90%) 

- combination (60% responses) 

- speed (30+% responses) 

General Observation: 

• Change requests for speed are least frequent. 

A.4.3 Coordination of Change Requests with Dispatcher 

The following results address the level and types of coordination pilots conduct with dispatchers 
as part of making change requests. 

A.4.3. 1 Percent of Change Requests Coordinated with Dispatch 

• Percent of change requests coordinated with Dispatch 
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- 50% said <10% of time 

- 30% said 10-30% of time 

- 5% said 30-70% of time 

- 12.5 % said 70-90% of time (most of time) 

- Most pilots (80% said 30% or less of time), the rest tend to coordinate with Dispatch 
more frequently 

General Observation: 

• Only a small percentage of change requests are coordinated with Dispatch (~20%). A few 
pilots tend to check with Dispatch much more frequently. Not sure if this pertains to one 
specific operator. 

A.4.3.2 Type of Coordination with Dispatch 

The follow represent the type and level of coordination between pilot and dispatcher for change 
requests. 

Type of Coordination with Dispatch: 

• Dispatch initiated 

- <10% engagement 

• Pilot initiated, before change request is made to ATC 

- ~ 10 +% 

• Pilot initiates change request; no coordination with Dispatch 

- ~ 10 +% 

• Pilot advise Dispatch after the fact 

- >30% 

General Observation: 

• Pilots generally initiate change requests without Dispatch input; advise Dispatch later or not at 
all. Dispatch initiates what leads to change requests very infrequently (<10%). 

A.4.4 ATC Response to Change Requests 

The following represent the typical responses and frequency from ATC to change requests. 

A.4.4.1 Type of A TC Response to Change Request 

ATC Response to change request: 

• 4 of 7, with 7 representing ‘always’ and 1 representing ‘never’ are immediately approve 

• 4.7 of 7 are cleared after standby 

• 3.1 of 7 are amended 

• 4.3 of 7 deferred to next controller 

• 2.8 of 7 denied 

General Observation: 

• ~2/3 of time approved with conditions. Slightly less than 40% are denied or deferred to next 
controller. 
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A.4.4.2 Reason for ATC Denial of Change Requests 

Reason for ATC Denial 

• Traffic/traffic congestion, weather, metering, ATC workload: 

— Metering more often the occurrence 

— Controller workload, traffic congestion second, weather routing next 
General Observation: 

• No definitive trends are noted. 

A.5 Tools 

The following provides an overview of tools employed by dispatchers and pilots for flight 
planning/re -planning and monitoring. Effectiveness and short comings are also examined based 
on the survey results. 

A. 5.1 Dispatch Tools 

A.5. 1.1 Available Flight Planning Capabilities - Dispatch 

Available Flight Planning Capabilities - Dispatch: 

• Company personnel with tools (67%) 

• Automated monitoring in-house (33.3%) 

• Company personnel without tools (25%) 

• 3'^‘* party automated monitoring (16.7%) 

• Minor reference to in-house weather department 

General Observation: 

• Most capabilities include tools (-75%). 

A.5. 1.2 Tools for Monitoring Flight Efficiencies (Dispatch Perspective) 

The following tools for monitoring flight efficiencies were identified in the User Survey: 

• Sabre flight planning (used by the Low-Cost Airline surveyed) - Sabre services include 
dynamic flight planning, i.e., ability to run route scenarios, double check winds, overfly 
fees, etc., and can re-optimize during flight. The exact means for how this operator utilizes 
Sabre’s services is not specifically addressed in the User Survey. 

• Flight planning SW 

• Flight Explorer 

• Flight planning engine (Phoenix) - (not sure if this is used primarily pre-departure or also 
while aircraft is already en route 

• ATC weather feeds for big picture analysis 

• Contact crews via phone if needed 

• Flight status monitor (from FAA) - feed arrival/departure rates 

• Dispatcher can inquire position reports from Flight Management Computer (FMC) 

— Real-time information on current flight parameters 
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• Very effective re-dispatch/re-evaluation tool (unclear how currently used en 
route) 

General observation: 

• Tools provide a range of strategic and tactical capabilities with respect to monitoring flight 
efficiencies. Tactical tool capabilities seem to focus on Dispatch gaining access to a specific 
aircraft’s FMC for position reports associated flight parameter data and do not appear to 
provide a tactical integrated view of flight operations. TASAR has the ability to provide a more 
integrated tactical view from the specific own ship’s perspective, factoring in environmental 
constraints with respect to the current flight path. 

A.5.2 Pilot Tools 

The previous section examined dispatcher tools, associated information elements, and their relative 
effectiveness (or shortcomings) in the flight planning and in-flight re-planning processes. This 
section addresses the same topics from the pilot’s tools perspective for in-flight re-planning. 

A.5.2. 1 In-flight Re-Planning Capabilities for Pilots 

The following represent in-flight planning tools available to pilots in decreasing order of use / 
utility as identified in survey responses. 

• In-flight re-planning capabilities for pilot: 

- FMS (100% response, i.e., always used) 

- Company provided (75%) 

- Automatic cockpit tools (62.5%) 

- Manual cockpit tools (50%) 

— Almost no 3“^ party support 

— Other minor contributors to capabilities are 

• In-flight internet weather (likely the Fractional Operator) 

• Boeing wind update program (likely air transports operator(s)) 

• Ground weather radar data via internet (likely Flight Operations, or pilots 
bringing it on-board) 

• iPad Class 1 WiFi (likely provisioned by the Fractional Operator, or pilots 
bringing it on-board). 

A.5.2.2 Tool Effectiveness - Company Personnel Support without Tools 

• Tool Effectiveness - Company Support - without tools: 

- 60% of pilots do not use this approach 

- For those using this approach, this approach is viewed not to be very effective. 

A.5.2. 3 Tool Effectiveness - Company Personnel Support with Tools 

• Tool Effectiveness - Company Support - with tools: 

- Much greater use than for case without tools (Section 7.2.2) (80+% use) 

— Considerably effective, particularly for Extremely Challenging and Moderately 
Challenging flights (the more challenged/impacted the flight, the more effective). 
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A.5.2.4 Tool Effectiveness -Automated Monitoring and Advisory Service, Company 

• Tool Effectiveness - Automated Monitoring and Advisory Service, Company Resource: 

- Not used by 30 to 40% of respondent organizations 

- When used, effectiveness viewed best for most impacted flights 

• Very effective to effective in those cases. 

A.2.5.5 Tool Effectiveness - Automated Monitoring and Advisory Service, Party 

• Tool Effectiveness - Automated Monitoring and Advisory Service, 3’^‘^ Party Service: 

- -80% do not use this approach of support 

- When used, effectiveness viewed best for most impacted flights, very effective to 
quite effective. 

A.5.2.6 Tool Effectiveness - In-flight Re-Planning by Pilots with Tools 

• Tool Effectiveness - In-flight re-planning by pilots, with tools: 

- Quite heavily used; >90%, with some drop off for extremely challenged flight, 
perhaps due to workload? 

— Very to moderately effective for all types of impacted flights. 

A.5.2. 7 Tool Effectiveness - In-flight Re-Planning by Pilots without Tools 

• Tool Effectiveness - In-flight re-planning by pilots, without tools 

- Used -70% of time 

— Somewhat effective at best. 

A.6 Information Source Assessment - Dispatch 

A.6.1 Dispatch Information Sources - Fundamental and Most Valuable Rating 

The following information sources used by dispatchers are viewed as fundamental to the flight 
planning process. An effectiveness rating is also provided based on survey results. 

Dispatch Information Sources - fundamental and most valuable rating: 

• Convective weather info - all want accurate, timely info - viewed fundamental 

• Airspace status - all want accurate and timely info - viewed fundamental 

• Wind speed, direction, temperature (80+%) - also rated high as a fundamental need 

• Airport facility status, weather / traffic info (80+%) also rated high as a fundamental need 

All seek better information, not clear how good it is for them today from survey. 

A.6.2 Importance of Information Sources for Dispatch 

The following rate the importance of information for Dispatch in-flight re-planning (by decreasing 
order of priority): 

• Accurate Convective Weather Eorecasts and updates (58.3%) - Priority 1 

- Some rated it 2 (25%), 4 and 5 at 8.3% each 

• Wind speed, direction temperature - Priority 4 (50%), some also 1, 2, 3, with 3 more 
prominent (25%) than 2 (16.7), and 1 (8.3%) 
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• Airspace Status was priority 2 and 3 (33.3%, 41.7%, respectively) 

• Airport facility status, weather, traffic info - broad 1,2,3, 4 priority with 3 (33.3%) the 
highest, and 2 and 4 right behind (25%). 

General Observation: 

• Convective Weather is the highest priority source; airspace status and airport facility 
information sources are approximately equal as the next highest priority, with wind rated of 
lowest priority. 

A.6.3 Effectiveness of Information Sources for Dispatch 

The following ratings were received regarding the effectiveness of information sources for in- 
flight re-planning. 

Effectiveness of Information Source: 

• Airspace Status - 5.7 of 7 (7 being most important) 

• Accurate Convective Weather Forecasts and updates - 5.4 of 7 

• Wind speed, direction temperature - 5.2 of 7 

• Airport facility status, weather, traffic info - 5.1 

General Observation: 

• Airspace status is 1, Convective Weather 2, Wind 3, Airport facility 4 in terms of order of 
decreasing order of effectiveness. There is not a lot of differentiation among these sources per 
survey results. 

A.6.4 Deficiencies of Information Sources 

The following identifies what information is currently either lacking or of insufficient quality (e.g., 
in terms of its availability, accuracy, and/or timeliness), that prevents Dispatch from achieving 
effective en route re-planning to enable the unconstrained flight in changing environmental 
conditions. 

Lacking info / insufficient quality rating of Information Sources for Dispatch: 

• Convective Weather (Collaborative Collective Forecast Product - CCFP) 

- More frequent updates desired 

- Coverage of forecast areas often quite large 
— Level of resolution could be refined further 
— Anywhere in oceanic airspace 

Suggests weather information improvement opportunities. 

• Winds, speed/direction, temperature 

— Great value to have actual winds to utilize while in flight 

• Sabre Flight Plan Manager already provides updates 4 times a day (averages 
the 12 hour reading twice) 

Suggests an opportunity for improved information. 

• Airspace status (SUA, traffic management initiatives, etc.) 

— Real time information would be excellent (Opportunity?) 
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— Better integration with Flight Explorer or other Aireraft Situation Displays 
(Opportunity?) - This is more a Ground Display of the big picture, not a flight deck 
display. 

— Information changes so rapidly, it is difficult to keep up when monitoring 10 to 25 
flights 

— Delays due to Overhead stream, aircraft limiting altitude 

• When aircraft re-file coming out of Airspace Flow Program (AFP), how 
does one know what routes may become available? (Opportunity?) 

• Airspace facility status, weather, traffic 

— Real-time Airport Facility Braking Action web-site (similar to Runway Visual 
Range (RVR)) would be excellent; during snow storms 
— While improved, still have time lags in information pushed out to Flsers and 
Operations Control Center 

• This is probably due to validation processes required (Opportunity?) 

— Inbound holds - are they the result of just switching runway configurations or is 
there something bigger going on? 

• Other 

— Current Pilot Reports (PIREP) information from other flights (Opportunity?) 

- Time due to workload is an issue for dispatch. Dispatch requires easy to use 
information systems with associated tools. This is consistent with feedback that 
Dispatch tends to focus on flights pre-departure and not as much for en route re- 
planning due to workload. 

General Observation: 

• Timeliness, accuracy, and breadth/extent of information must continue to improve to enable 
effective flight re-planning. At the same time information management is required to avoid 
dispatcher information overload of excessive information detail and rapidity of updates. This 
requires intelligent automation to support dispatchers to allow them to “manage” the planning 
and re-planning of flights while keeping workload at reasonable levels. 

The following represent factors identified by dispatchers surveyed that constrain re-planning of 
the current flight (in decreasing order of severity): 

• Fuel reserve is most significant constraint factor (4.4 of 7, with 7 as most severe impact) 

• Fack of accurate and timely weather information (4.2 of 7) 

- TASAR Opportunity 

• Fack of sufficient information on airspace status (3.6) 

• Fack of sufficient flight status information (3-) 

• Connecting flight (2-) 

General observation: 

• Clearly both Dispatch and the aircraft can benefit from improved information, particularly 
related to weather. Airspace information seems to be less of a factor. TASAR likely plays a 
tactical role in re-planning of the flight, while Dispatch is more strategic. 

Effectiveness of Current Flight Optimization Capabilities (and available time): 
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• Only moderately effective (4+ of 7) 

— Slightly better for Minimally Impacted, slightly worse for Extremely Impacted 
Weather 

General observation: 

• Dispatchers overall rate current flight optimization capabilities, and available time to do so as 
moderately effective (~4 out of a best rating of 7). 

A.6.5 Information that Would Significantly Improve the Flight Re-Planning Process 

The following information elements and associated improvements were identified by dispatcher 
survey respondents that they believe would significantly benefit the flight re-planning process. 

Beneficial Information Elements for Elight Re-Planning: 

• Accurate convective weather forecasts, i.e., updates on already occurring weather 

— Areas of moderate to severe/extreme turbulence 
— When convective activity is expected to affect route 

• Movement and speed of storms 

• Winds, speed and direction, temperature 

— Large change over short distances may help with turbulence forecast for a specific 
route 

• Airport status (SUA, traffic management initiatives, etc.) 

- Real-time updates would be excellent 

- Airspace congestion, constraints, closure 

- Overhead stream issues 

• How long a wait versus filing another route; stuck in conga line - or another, 
better route for $100 to $200 additional cost 

• Airport facility status, weather, and traffic 

— National Airport Eacility Braking Action website 

— Aerodrome closures, take-off and landing runways in use; RVR information; 
Navigation and runway NOTAMS 

- If airport back-ups occurring, would like to know so could slow down and save fuel 
General Observation: 

• A number of improvement opportunities are identified. It would be beneficial to more closely 
evaluate the major aspects of flight planning / re-planning processes and how they translate 
into successful conduct of the flight. Eurther analysis on which and how improvements in 
information quality will provide improved flight planning and in-flight re-planning is 
warranted. 

Additionally, the roles of Dispatch in planning and in-flight re-planning, in conjunction with 
the role of the flight deck (applications and flight crew capabilities) in performing in-flight re- 
planning using tools such as TASAR, should be clearly delineated and allocated synergisticahy 
for maximum benefit. In addition, re-planning in the presence of changing environmental 
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factors needs to be accomplished in a consistent way with current and future ATC processes 
and procedures, again to be synergistic in nature. 

General observation: 

• Tools are generally employed. Without tools, any support is not viewed as effective. Hands- 
on company support is used significantly (80+ %) and is moderately and at times very 
effective. Automated monitoring and advisory services are used less frequently but when used, 
are effective. Most (80%) do not use 3"^ party automated monitoring and advisory service 
support. Effectiveness is always best for the more impacted flights (extremely and moderately 
challenged). Pilot in-flight re-planning with tools is heavily used (90%) and very to moderately 
effective (perhaps used a bit less when extremely challenged - perhaps due to pilot workload 
(?)). Without tools, pilots still attempt to try to consider re-planning, but only with somewhat 
effectiveness at best. 

A.7 Flight Re-Planning Organizational Policies, Constraints, and Cost Factors 

This section examines organizational policies and procedures utilized by the operators surveyed 
with respect to the pilot’s ability to initiate in-flight re-planning of the current route. Also examined 
are constraints identihed to the flight planning / re-planning process, and cost factors affecting 
operations. 

A.7.1 Organizational Policies and Procedures for Flight Changes 

Based on User Survey responses from dispatchers from the three operators, a broad range of 
organizational policies and procedures are utilized by the operators for flight changes. 

More than half of the responses (7 of 12) indicate that pilot can initiate altitude and speed changes 
on their own discretion, while route changes must be done via dispatch. 

A small number of respondents (2 of 12) indicated that no policies are in place (conjecture is that 
this is likely Flight Options, due to the nature of their more flexible and diverse nature of end users 
and transportation needs). 

A small number of respondents (2 of 12) indicate that pilots may initiate (flight plan changes), but 
these must be approved by Dispatch. 

One respondent indicated that the pilot can initiate a change request without Dispatch input as long 
as it is within the context of the predefined Operations Control Manual. 

General observation: 

• Pilots have considerable latitude for flight changes, particularly for altitude and speed changes, 
guided by the company Operations Control Manual. Request for route changes are more likely 
to require Dispatch approval. Sufficient pilot empowerment is in place at the surveyed 
operators to allow utilization of TASAR capabilities to seek improvements to the current flight 
plan. 

A.7.2 Flight Optimization by Dispatchers 

Dispatchers were asked regarding the extent of time they generally spend on optimization of each 
flight and to what thresholds of flight time savings and/or fuel savings they would consider re- 
planning of a flight. 
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A 7.2.1 Time Spent on Flight Optimization 

Dispatchers were surveyed concerning time spent per flight on optimization of the flight: 

• 50% answered less than 5 minutes 

• 41.7% answered 5 to 10 minutes 

• 8.3% answered 1 1 to 25 minutes 

Note: One wonders about the trade-off on time spent versus savings achieved - if airlines are 
not focused on this (i.e., not spending more or sufficient time to improve efficiency of flights), 
then they either do not have the means to do better in the way of tools of available quality 
information, or it is not a big cost issue (or they are not business focused - which is unlikely). 

A follow-up question would be concerning which flights should Dispatch expend more effort 
on optimization - long haul and/or international flights? Also, once operators are able to 
operate in more of a “free flight” airspace perhaps in NextGen, with fewer constraints imposed 
(versus the more rigid route structures of today’s operations), then more significant gains can 
be made, and greater focus on optimization by Dispatch may be warranted. 

A 7.2.2 Time and Fuel Savings Threshold for Re-Planning (Dispatch View) 

Dispatchers were asked at what level of savings (flight time and/or fuel) that they would consider 
an en route (in-flight) re-planning of a flight. 

Time Savings Threshold for En Route Re-plan: 

• Dispatchers responded with ~3 minutes average flight time savings (but also had wide 
variance in responses up to 15 minutes) 

Fuel Savings Threshold for En Route Re-plan: 

• Dispatchers responded with -150 lbs. average flight time savings (but also had wide 
variance in responses up to 400 lbs.). 

A.7.3 Flight Planning Constraints 

This section examines survey responses related to constraints faced by Dispatch and Flight 
Operations in flight planning and for en route in-flight re-planning processes. 

A 7.3.1 Flight Planning Constraints (Inability to Achieve the Unconstrained Flight) 

Dispatchers were probed to identify the extent that ATC-preferred routes, TFM Initiatives, and 
SUA had on being able to achieve an unconstrained flight plan. 

• Due to ATC Preferred routes, TFM Initiatives, SUAs 

— 50% of dispatchers indicated that flights are very to significantly constrained due 
to these factors 

— 25% indicate moderately constrained 

— 25% indicate no or little constrained flights (conjecture that this is likely an input 
from the Fractional Operator surveyed, who are viewed to be less impacted by ATC 
constraints due to their operations from/to non-hub airports.) 
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A.7.3.2 


Company Constraints for En route Re-Planning (Flight Operations View) 

The following represent the constraints and their priorities to be considered by pilots when 
initiating en route re -planning as viewed from the Flight Operations perspective; 

• ‘Arrival time for critical connections’ 

— This is the highest priority constraint for Global Network Carrier surveyed (1 of 7, 
with 1 being most significant constraint factor) due to their networked route 
structures needing to support connect flights. 

• The Low-Cost Airline only rates this (4 of 7) 

• The Fractional Operator rates this least important (7 of 7) since meeting 
connecting flights is not a factor for Flight Options. 

• ‘Requirements for fuel stop’ are the highest constraint for the Low-Cost Airline (1 of 7), 
followed by the Fractional Operator (2 of 7), and Global Network Carrier (3 of 7). 

• ‘Organization’s priority for the flight’ is the most important constraint for the Fractional 
Operator (1 of 7) due to their fractional ownership business model 

— Second most important to the Global Network Carrier (2 of 7) 

- Followed by the Low-Cost Airline (3 of 7). 

• ‘Arrival time for gate availability’ and ‘arrival sequence with other organization flights’ 
are rated relatively low on constraint importance. 

A. 7.3.3 Cost Factor Rating 

This section identifies and rates cost factors provided by Flight Operations personnel from the 
operators surveyed. 

Flight Path Performance Cost Factors: 

• Fuel cost is the #1 priority for all three operators 

• Schedule integrity is tied for #1 for the Fractional Operator, #2 for the two airline operators 

• Ride quality is also tied for #2 for the Global Network Carrier, #3 for the Low-Cost Airline, 
#4 for the Fractional Operator (may suggest that VIPs and other passengers for this operator 
are more ardent fliers able to understand and handle rougher flights compared to the general 
flying public on air transport aircraft (?) 

• Flight time is #3 for the Fractional Operator, #4 for the two airlines surveyed 
Revenue Impact: 

• For the Low-Cost Airline - completion, on-time performance, and fuel efficiency are all 7 
of 7 (7 being most important) 

— Ride quality for Low-Cost Airline is 5 of 7 

• The Global Network Carrier - completion is 7 of 7, on time performance and fuel efficiency 
are 6 of 7, ride quality only 2 of 7 

• For the Fractional Operator - completion and fuel efficiency are highest (6 of 7), on-time 
is 5 of 7, ride quality is 3 of 7. 

A.8 Survey Review and Assessment Results Summary 

Section 4.1.2 provided the review and assessment of results related to the TASAR User Survey, 
with the objective to provide “findings and recommendations for the TASAR concept and 
implementation strategies that would accelerate user adoption of TASAR.” 
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Recommendations and observations fall into two categories which are then summarized below: 

1) Equipage for TASAR 

2) TASAR cost benefits, usability, and synergy with Dispatch and ATC processes. 

A.8.1 Equipage for TASAR 

A positive finding, from an equipage perspective, is that the operators surveyed in many cases are 
beginning to equip with the type of avionics systems and associated EFB and data communication 
capabilities needed to enable TASAR. ADS-B OEIT (primarily 1090 MHz), EFB Class (1, 2 or 3), 
internet access (via terrestrial and/or satellite networks) and Data Comms (ACARS, CPDEC) are 
already in their plans. ADS-B fN (1090 MHz and/or UAT) plans are considerably less certain. 

In this regard, the Fractional Operator, with its fleet of business and regional aircraft, is already 
well equipped with data connectivity to ground systems. Air transport operators, particularly the 
Global Network Carrier, are more reliant on ACARS and Data Comms and are currently not as 
connected to internet data networks, but this is improving. It is recommended that data connectivity 
is strongly encouraged for all operators to provide the most effective information access for 
TASAR. While TASAR’s traffic awareness is highly desirable, a prolonged period of mixed ADS- 
B equipage (both ADS-B OUT and ADS-B IN) is likely a reality for several more years. Cost 
benefits from TASAR may help with this, but these must be fairly significant to create the pull for 
ADS-B equipage on their own. More likely, additional beneficial ADS-B applications for NextGen 
will need to assist with this pull. 

The most significant and encouraging findings are that the operators surveyed, representing a 
significant cross-section of aircraft operators, are beginning to have avionics and associated EFB 
and data communications capabilities capable of supporting early introduction of TASAR. 

A.8.2 TASAR Cost Benefits, Usability, Synergy with Dispatch and ATC Processes 

In order to achieve a positive business case for TASAR, two key requirements must be achieved: 

1) Access to relevant, high quality (i.e., accurate, timely {sufficient update rates, sufficient 
latency}) information sources (both ground-based and flight-deck based) 

2) Synergistic integration of TASAR with available flight (re)planning tools and processes 
used by dispatchers and pilots, while also being consistent with ATC processes (change 
requests, traffic flow management including arrival flows). 

Without quality and complete information, TASAR is unlikely to provide reliable cost benefits. 
Pilot acceptance of TASAR is likely dependent on TASAR providing consistent and believable 
trajectory change recommendations with indicated savings in fuel and/or flight time. In addition, 
in the longer term, TASAR’s utility should be integrated in a consistent manner with other flight 
planning, flight optimization processes utilized by Dispatch and should be consistent with ATC 
processes and procedures. 

While initial studies indicate the benefits of TASAR [5], a thorough assessment of TASAR cost 
benefits is likely required. Current on-going and planned flight simulations (University of Iowa 
Operator Performance Laboratory pilot evaluations in the use of TASAR using a Boeing 777 flight 
simulator), flight evaluation (Advanced Aerospace Solutions’ flight trial of TASAR using their 
Piaggio Avanti P 1 80 aircraft), and planned HITE experiments by NASA can assist in development 
of the TASAR business case. 
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The following represent a collection of general observations and comments regarding current flight 
planning and in-flight re-planning procedures, tools, information sources and their effectiveness 
(or lack thereof) as determined from survey responses from pilots, dispatchers, and flight 
operations personnel from the operators surveyed: 

1) From a Dispatch perspective, significant weather as observed by Dispatch or per notifica- 
tion from the pilot or ATC is the primary reason for re-planning of the flight. Airspace 
disruption notification from ATC follows weather as the next key factor for re-planning. 

2) Dispatchers rate the effectiveness of current flight optimization capabilities (and the 
available time to perform those duties) as moderately effective. These capabilities were 
slightly more effective for “minimally impacted” flights and slightly worse for “extremely 
impacted” flights due to adverse environmental factors. 

3) In assessing survey responses, it is observed that weather is a primary consideration for 
dispatchers, with ATC constraints, airspace disruptions and other constraints being 
somewhat secondary factors (still important but not at the level of weather). Conversely, 
for pilots, ATC constraints and airspace disruptions are larger factors, with en route 
weather being a secondary, less constraining factor in in-flight re-planning. 

4) Tools provide a range of strategic and tactical capabilities with respect to monitoring flight 
efficiencies. Tactical tool capabilities seem to focus on Dispatch gaining access to a 
specific aircraft’s FMC for position reports and associated flight parameter data and do not 
appear to provide a tactically integrated view of flight operations. TASAR has the ability 
to provide a more integrated tactical view from the specific own ship’s perspective, 
factoring in environmental constraints with respect to the current flight path. 

5) Timeliness, accuracy, and breadth of information must continue to improve to enable 
effective flight re -planning. At the same time, information management is required to avoid 
dispatcher information overload of excessive information detail and rapidity of updates. 
This requires intelligent automation to support dispatchers to allow them to “manage” the 
planning and re -planning of flights while keeping workload at reasonable levels. 

6) It is evident that both dispatchers and the pilots can benefit from improved information, 
particularly related to weather. Airspace information seems to be less of a factor. TASAR 
likely plays a tactical role in re-planning of the flight, while Dispatch is more strategic. 

7) From pilot survey inputs concerning use of tools, it is noted that tools are generally 
employed. Without tools, any support is not viewed as effective: 

a. Hands-on company support is used significantly (80+ %) and is moderately and at 
times very effective. Automated monitoring and advisory services are used less 
frequently but when used, are effective. Most (80%) do not use 3'^‘^-party automated 
monitoring and advisory service support. Effectiveness is always best for the more 
impacted flights (extremely and moderately challenged) due to adverse 
environmental conditions. 

b. Pilot in-flight re-planning with tools is heavily used (90%) and very to moderately 
effective (used a bit less when extremely challenged - perhaps due to pilot 
workload). Without tools, pilots still attempt to try to consider re-planning, but only 
with somewhat effectiveness at best. 
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c. Survey results and insight into the pilot tools used (except for FMS, which is always 
used), are not very specific and would require further investigation and dialog with 
pilots. 

8) Pilots have considerable latitude for making flight changes, particularly for altitude and 
speed changes, guided by the company Operations Control Manual. Request for route 
changes are more likely to require Dispatch approval. Sufficient pilot empowerment is in 
place at the surveyed operators to allow utilization of TASAR capabilities to seek 
improvements to the current flight plan. 

9) From a Dispatch perspective pertaining to time spent on flight optimization, there is a trade- 
off on time spent versus savings achieved; if airlines are not focused or motivated to spend 
additional time to improve the efficiency of flights, then they either do not have the means 
to do better (i.e., in the way of tools and available quality information), or it’s not a big 
cost issue to be considered. It is unlikely that they are just not focused on seeking cost 
improvements due to lack of focus and is likely related tool availability. 

a. A follow-up question would be concerning which flights should Dispatch expend 
more effort on optimization - long haul and/or international flights? Also, once 
operators are able to operate in a more “free flight” airspace perhaps in NextGen, 
with fewer constraints imposed (versus the more rigid route structures of today’s 
operations), then more significant gains can be made, and greater focus on 
optimization by Dispatch may be warranted. 

10) Dispatcher can inquire position reports from FMC and derive additional real-time 
information on current flight parameters, which is viewed as a very effective re-dispatch 
and re-evaluation tool. 

a. From survey responses. Dispatch tends to play a relatively limited role for in-flight 
re-planning. This is particularly the case for the Global Network Carrier surveyed, 
who only provides support services while the aircraft is in-flight when prompted by 
pilot requests. 

b. A potential area of research is to determine to what extent should Dispatch focus 
on in-flight re-planning, which is currently not their focus, or should this be 
delegated to flight-deck tools, e.g., TASAR. What is the proper balance of Dispatch 
versus aircraft-based in-flight re-planning to ensure synergy? In addition, to what 
extent can TASAR take on flight planning typically done by dispatch, particularly 
in future NextGen operations that support “free fiighf ’ capabilities? 

1 1) TASAR, with good (i.e., pertinent, accurate, and timely) information on ATC metering and 
flow management, and weather information (especially en route and at the destination 
airport) has the potential to provide significant tactical re-planning capabilities for 
operational efficiency. With TASAR the key issue is its usability (i.e., providing benefits 
while at the same time being streamlined with operator dispatch, own ship flight procedures 
using the FMS, and with ATC’s overall air traffic control paradigm (change request 
clearances, traffic flow management, arrival management, etc.). 

12) A number of improvement opportunities are identified as a result of survey responses. It 
would be beneficial to more closely evaluate the major aspects of flight planning and re- 
planning processes and how they translate into successful conduct of the flight. Further 
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analysis on which information elements and how improvements in information quality will 
provide improved flight planning and in-flight re-planning is warranted. 

13) Additionally, the roles of Dispateh in planning and in-flight re-planning, in eonjunetion 
with the role of the flight deek (applieations and flight erew eapabilities) in performing in- 
flight re-planning using tools sueh as TASAR, should be clearly delineated and alloeated 
synergistieally for maximum benefit. In addition, re-planning in the presenee of changing 
environmental factors needs to be aeeomplished in a eonsistent way with eurrent and future 
ATC processes and procedures, again to be synergistie in nature. 

In summary from an aireraft equipage perspeetive, TASAR is poised to be readily aehieved, with 
the possible exeeption of ADS-B IN. A positive cost benefit business case is a key requirement for 
operators to eontinue to equip and enhanee their avionies, EFB and data eommunieations level of 
equipage for their aireraft fleets. Perhaps the most significant challenge is the development of a 
more robust eost benefit assessment for TASAR that supports synergistic usability with Dispatch 
and ATC processes as part of the in-flight re-planning to aehieve operational efficieneies in the 
presenee of changing environmental eonditions (e.g., weather and airspaee disruptions). 
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Appendix B TASAR EFB Standards Adherence Requirements 

This appendix documents the detailed results of the EFB standards adherence requirements 
assessment summarized in Section 4.2.2, with focus primarily on EFB hardware and software 
requirements, including installation considerations. 

B.l Determination of EFB "Class" Anticipated for TASAR 

Before addressing EFB “Class” for TASAR, it is necessary to provide some context on the use of 
EFBs in the flight deck, including a few definitions provided by FAA on their intended and allowed 
use. FAA Advisory Circular AC 120-76C [13] serves as the key document providing Guidelines 
for Certification and Operational use of EFBs and associated applications. 

With significant strides continually being made on increasingly capable and versatile portable 
computing devices (hardware, software, and applications), there is a strong desire by aircraft 
operators, aircraft manufacturers, and avionics manufacturers to leverage the computing power 
and connectivity offered by EFBs for applications that provide operational benefits and improved 
situational awareness in the flight deck. The relatively low-cost of these systems potentially 
provides an effective path for new flight-deck capabilities that supplement and complement 
traditional avionics systems that provide Communication, Navigation, Surveillance support for the 
pilot to conduct flight operations. These systems also potential offer a relatively low-cost path for 
system retrofit of new capabilities. 

FAA has recently updated the original AC-120-76 document to the newly released AC 120-76C 
[13] and is already working on a future update. While trying to accommodate end user innovation 
for new EFB-based applications, FAA is also looking to ensure interference-free operation to on- 
board certified avionics functions. As such, FAA has established guidelines and definitions for the 
use of PEDs as EFBs (also referred to as Portable EFBs). These devices may be carried onboard 
and used by the pilot / flight crew or could be mounted for use in the cockpit. Computing devices 
may also be permanently installed in the flight deck (also referred to as Installed EFBs). Depending 
on the application and intended use, PEDs and EFBs may be used standalone or they may interface 
directly to or indirectly to (via an AID) to avionics systems. When interfacing to avionics, the 
PED/EFB can be read-only or may also transmit to onboard avionics systems. As such, FAA has 
defined requirements for PED/EFB use for these operations that will be identified below, with 
focus on applicability to TASAR. 

The following definitions apply to PED/EFB use in the flight deck. It should be noted that many 
people tend to use the term EFB in a general sense, while FAA uses these terms in more specific 
context. While the user community envisions broad use of PEDs/EFBs for a wide range of 
increasingly capable applications, FAA currently restricts the definition of PEDs/EFBs to 
applications currently allowed to replace paper documents (i.e.. Type A applications) or those that 
provide some sort of algorithmic processing, e.g., performance calculations (i.e.. Type B 
applications). New applications that do not necessarily map directly into these defined categories 
(i.e., type of application, e.g.. Type A, B, or C) may need to be developed, validated and evaluated 
by FAA certification and operational approval personnel for their intended function before gaining 
approval. EFB Types software is further examined in Section 4 below. 

Definitions 
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The following definitions are eurrently used by FAA as part of EFB guidanee document AC 120- 
76C and are applicable to the TASAR EFB assessment presented here: 

Electronic Flight Bag (EFB) - an electronic display system intended primarily for flight deck use 
that includes the hardware and software necessary to support an intended function. EFB devices 
can display a variety of aviation data or perform basic calculations (e.g., performance data, fuel 
calculations). In the past, some of these functions were traditionally accomplished using paper 
references or were based on data provided to the flight crew by an airline’s flight dispatch function. 
The scope of the EFB functionality may include various other hosted databases and applications. 
Physical EFB displays may use various technologies, formats, and forms of communication. An 
EFB must be able to host Type A and/or Type B software applications. 

Portable Electronic Device (PED), Title 14 Code of Federal Regulations (14 CFR) Section 91.21; 
§ 121.306; part 125, § 125.204; and part 135, § 135.144 refer to PEDs and place restrictions on 
the in-flight use of PEDs. There are two types of PEDs and two methods of compliance with these 
regulations. 

(1) The non-EFB PED method of compliance with PED regulations is in the current edition of AC 
91.21-1 [15], Use of Portable Electronic Devices Aboard Aircraft. Use of these PEDs is prohibited 
in instrument flight rules (IFR) flight operations, except in cruise flight. 

(2) The EEB PED method of compliance with PED regulations is in FAA Order 8900.1 Flight 
Standards Information Management System (FSIMS) [14] and AC 120-76C [13]. 

Transmitting Portable Electronic Devices (T-PED), PEDs that have intended radio frequency 
(RE) transmission capabilities. 

B.2 Classes of EFB - Hardware Perspective 

Class 1 EFB Hardware - portable commercial off-the-shelf (COTS)-based computers, considered 
to be PEDs with no EAA design, production, or installation approval for the device and its internal 
components. Class 1 EFBs are not mounted to the aircraft, connected to aircraft systems for data, 
or connected to a dedicated aircraft power supply. Class 1 EEBs can be temporarily connected to 
an existing aircraft power supply for battery recharging. Class 1 EFBs that have Type B 
applications for aeronautical charts, approach charts, or an electronic checklist must be 
appropriately secured and viewable during critical phases of flight and must not interfere with 
flight control movement. 

Portable Class 1 EFB components are not considered to be part of aircraft type design; i.e., not in 
the aircraft Type Certificate (TC) or Supplemental Type Certificate (STC).) 

Class 2 EFB Hardware - portable COTS-based computers, considered to be PEDs with no FAA 
design, production, or installation approval for the device and its internal components. Class 2 
EFBs are typically mounted. They must be capable of being easily removed from or attached to 
their mounts by flight crew personnel. Class 2 EFBs can be temporarily connected to an existing 
aircraft power supply for battery recharging. They may connect to aircraft power, data ports (wired 
or wireless), or installed antennas, provided those connections are installed in accordance with AC 
20-173. 

Portable Class 2 EFB components are not considered to be part of aircraft type design; i.e., not in 
the aircraft TC or STC. 
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Class 3 EFB Hardware - EFBs installed in accordance with applicable airworthiness regulations. 
Refer to AC 20-173 for guidance on the installation of EFB components. 

Based on the above FAA definitions of Classes of EFBs, it is noted that a FED is by definition not 
considered as part of the aircraft design (i.e., not part of a TC or STC). An Installed Electronic 
Device is by definition Class 3 and will require TC/STC approval. 

The TASAR application, as described in Section 1, does not require to be hosted in an Installed 
EFB in the flight deck, but can be hosted in a FED, i.e., Fortable EFB. Thus a Class 3 EFB is not 
required for TASAR. Note: If desired, TASAR could be integrated as part of a Class 3 EFB when 
integrated with other already approved software applications. It would need to be demonstrated 
that the TASAR software (operating system and application) would not adversely affect and 
interfere with already installed, certified software applications. 

B.3 Typical EFB System Components 

Figure B-1 illustrates typical components associated with an EFB (Figure B-1 is from FAA AC 
20-173, “Installation of Electronic Flight Bag Components”, [16]). 
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Figure B-1 Typical EFB System Components 

When TASAR is implemented directly as an EFB, it will need to be a “mounted FED,” requiring 
interface (wired / wireless connectivity) to aircraft systems, and primary power from a source of 
aircraft power. This requires TASAR to be Class 2 EFB. When TASAR is implemented as a FED 
(i.e., display, processor) to be interfaced through an AID {referred to as Data Interface Device in 
Figure B-I), it could potentially be implemented as a Class 1 EFB/FED. In this case, the AID (i.e.. 
Data Interface Device) takes over the burden of providing the necessary interfaces and protections 
to the aircraft systems and primary aircraft power. The assessment in this report treats the TASAR 
EFB as either a direct EFB implementation, or as an indirect interface to an AID, with the AI D 


105 






being part of TASAR. Thus this assessment will only consider the EFB standard adherence 
requirements as a Class 2 EFB for TASAR. 

The EFB system illustrated in Figure B-1 must ensure protection and isolation of the EFB 
application from installed avionics systems in terms of system security against vulnerabilities and 
threats, e.g., computer viruses, worms, unauthorized access, and malicious access. 

B.4 Class 2 EFB Approval Requirements 

This section examines the approval requirements for a Class 2 EFB for TASAR. In addition to AC 
120-76C, another key guidance document for FAA EFB Authorization is FAA 8900. 1 Change 47, 
Volume 4 “Aircraft Equipment and Operational Authorizations”, Chapter 15 “EFB Authorization 
for Use”, Section 1 “EFB Operational Authorization Process” [14]. 

B.4.1 High-Level Steps for Installation and Operational Approval of a Class 2 EFB 

The following represents the high-level steps needed to be followed for the Installation and 
Operational Approval of a Class 2 EFB for TASAR: 

1 . Applicant must obtain approval via TC or STC for initial alterations related to: 

a. mounting fixture installation 

b. installation of power and / or data connectivity 

Note: Any follow-on installation must use FAA-approved data. 

2. Manufacturer, provider, or installer must assure via testing that the Class 2 EFB provides 
interference-free operation 

a. If a data transmitter is used to transmit data to the Class 2 EFB, it must be tested to 
RTCA DO-160E, section 21, paragraph M. This ensures that conduction or radiation 
of emissions do not result in interference. 

3. Applicant must obtain TC, STC approval or DER approval for installation of antennas that 
provide data to the EFB, e.g., navigation, weather data 

Note: TASAR may fall into this category as it seeks to access information from network- 
enabled information services. However, since TASAR is of “Minor”, or “No Effect” EEC, the 
data integrity required may be relatively minor, and TC, STC, or DER approval requirements 
of installed antennas are to be determined with further analysis. 

FAA Involvement in EFB Approval Process 

The following FAA offices are involved in the EFB approval process, 1) Certification (AIR), 2) 
Aircraft Evaluation Group (AEG) - Flight Standards (AES), and 3) the POT 

The role of AIR is to issue approval of type design of installation for inclusion in the TC/STC. 

AEG may evaluate new EFBs and prepare an Operational Suitability Report (OSR). 

The POI conducts reviews and issues authorization by Operational Specification (OpSpec) or by 
Management Specification (MSpec) and Fetter of Authorization (LOA), A061. 

Operator Requirements 

The following are requirements to be met by the Operator for the intended function / new EFB 
capability, in this case TASAR: 
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1 . Develops the program for usage 

2. Completes an operational evaluation of the new eapability 

3. Ensures that the system performs its intended function 

4 . Documents non-interference per AC 91.21-1 [15] 

5. Ensures non-interference with and isolation from aircraft systems during transmission and 
reception 

6. Determines usage of hardware architectural features, persons, procedures, and equipment to 
eliminate, reduce, or control risks associated with hardware failure 

Note: Installed elements of Class 2 EEB must be entered into aircraft records when added or 
removed 

B.4.2 EFB Mounting Considerations 

Before addressing the EEB standards adherence requirements associated with mounting the 
TASAR Class 2 EFB, the following definitions (from FAA AC 120-76C) are provided to support 
the discussion: 

Mounted, Any portable device that is attached to a permanently installed mounting device. 

Mounting Device, These include arm-mounted, cradle, clips, docking stations, etc. 

Stowed, A portable device that is placed in a secure stowage location but is not available for use 
or view by the pilot in that location. 

Viewable Stowage, A portable device that is secured in an existing provision with the intended 
function to hold charts or acceptable portable device viewable to the pilot (e.g., kneeboards). 

From the TASAR application perspective, the TASAR EFB is expected to be mounted (either 
directly, or indirectly via an AID to provide the intended functions. The mounting device may be 
connected to data source(s), hardwired to an aircraft power source (or via a connector), and 
hardwired to an installed antenna. 

The mounting device must be evaluated to ensure operational suitability in all ground and flight 
operations and conditions. As such, the mounting device must: 

1) not interfere with flight crew duties 

2) be easily stowed when not in use 

3) must not obstruct primary or secondary fields of view 

4) must not obstruct egress. 

As the EFB is portable (i.e., not installed permanently as part of the flight deck), it must be easily 
removable, without tools, and by the pilot / flight crew member. The EFB must be accessible to 
the pilot / flight crew (if it is not accessible, then it must be installed via a certified installation via 
TC, amended TC or STC). The only exception to the accessibility criteria is for a remotely mounted 
antenna that provides signal reception to the Class 2 (also Class 1) EFB. 

Two types of EFB mounts can be considered, 1) a yoke mount or 2) a cockpit mount. A yoke 
mount requires FAA AIR approval, either as a TC, STC or amended TC. DER or field approval is 
not permitted. A cockpit mount requires AIR airworthiness approval and cannot be Field 
Approved. A cockpit mount represents the preferred mounting approach for TASAR. 
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B.5 EFB "Type" Considerations 

In order to address EFB standards adherenee requirements with respect to the EFB “Type” (i.e., 
with respect to EFB software), the following definitions (again from AC 120-76C) are referenced: 

Critical Phases of Flight, Includes all ground operations involving taxi, takeoff, and landing, and 
all other flight operations conducted below 10,000 feet, except cruise flight. 
Note: This definition of the critical phases of flight is per those in part 121, § 121.542. 

Approved Software, Software approved by the FAA using the current edition of RTCA/DO-178, 
Software Considerations in Airborne Systems and Equipment Certification, compliance, or other 
acceptable means. 

Note: As defined below for Type C Software - “Approved Software” applies to non-EFB Software 
that is major hazard or higher and thus requires DO- 178 for certification approval. 

Type A Software Applications, Type A applications are those paper replacement applications 
primarily intended for use during flight planning, on the ground, or during noncritical phases of 
flight. Examples of Type A software applications are listed in Appendix 1 in AC 120-76C. 

Type B Software Applications, Type B applications are those paper replacement applications 
that provide the aeronautical information required to be accessible for each flight at the pilot station 
and are primarily intended for use during flight planning and all phases of flight. Type B 
applications include miscellaneous, non-required applications (e.g., aircraft cabin and exterior 
surveillance video displays, maintenance applications). Examples of Type B software applications 
are listed in Appendix 2 in AC 120-76C. 

Type C Software Applications, Software approved by the FAA using RTCA/DO-178B 
compliance or another acceptable means. These are non-EFB software applications found in 
avionics and include intended functions for communications, navigation, and surveillance that 
require FAA design, production, and installation approval. Type C applications are for airborne 
functions with a failure condition classification considered to be a major hazard or higher. 

Precomposed Information, Information previously composed into a static, composed state (non- 
interactive). The composed displays have consistent, defined, and verifiable content, and formats 
that are fixed in composition. 

Hosted Application, Software running on an EFB that is not installed or considered part of aircraft 
type design. 

Interactive Information, Information presented on the EFB that, via software applications, can 
be selected and rendered in a number of dynamic ways. This includes variables in the information 
presented based on data-oriented software algorithms, concepts of decluttering, and selectable 
composition as opposed to precomposed information. 

Based on the above definitions, the following observations are made: 

Type A applications are primarily intended for use during flight planning, on the ground, or during 
noncritical phases of flight and are electronic paper replacement (i.e., they do not consist of specific 
algorithms and processing, but strictly depict precomposed database information. (Refer to 
Appendix 1 in AC 120-76C for a detailed list of approved Type A applications). 
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Type B applications are intended for use during critical phases of flight or have software and/or 
algorithms that must be tested for accuracy and reliability by applicant. (Refer to Appendix 2 in 
AC 120-76C for a detailed list of approved Type B applications). 

Sample Type B applications are 1) display of aeronautical charts viewable electronically and 
allows chart manipulation, 2) Electronic Checklists available in all phases of flight, 3) Weight and 
Balance calculations / algorithms, 4) performance calculations. These must be tested and proven 
by the applicant. 

While TASAR is currently neither a Type A or Type B application (i.e., not on the approved list 
of applications per Appendix 1 and Appendix 2 in AC 120-76C), TASAR has some key 
characteristics related to Type B software applications; 1) intended for use during flight planning 
(in case of TASAR, primarily during en-route phase of flight, but potentially during the later stages 
of climb, and early stages of decent), 2) includes variables in the information presented based on 
data-oriented software algorithms (in case of TASAR, using a variety of information sources for 
subsequent processing to determine trajectory change candidates), and 3) failure classification of 
no more severe than “Minor” failure effects. 

Note; While TASAR is similar to a Type B application, it is anticipated that it has a lesser threshold 
for acceptance / approval over traditional Type B applications; TASAR being an optional, 
supplemental, advisory support tool, that the pilot / flight crew can use at their discretion (i.e., can 
choose to ignore or disable at any time for any reason). Appropriate pilot training will ensure that 
pilot / flight crew will not be distracted by TASAR during flight operation while conducting 
normal operational tasks associate with the current flight. 

Based on the above definitions, PEDs/Portable EFBs (i.e. EFBs of Class 1 and Class 2) are limited 
to perform Type A and B application, which are of “Minor” EEC. In addition. Type C display of 
own ship position application is permitted for taxi speeds below 40 kts but is not allowed for 
airborne use, otherwise this would require use of an installed Class 3 EFB and would require DO- 
178B Software certification. This is not a consideration for the TASAR application, as own ship 
position is not part of the TAP HMI design [3]. 

Type B Software Considerations 

While TASAR is currently not defined as an EFB application, and is neither a Type A nor Type B 
software application, TASAR has many of the characteristics of a Type B application. 

Type B applications may be hosted by any Class EFB (Class 1, Class 2, or Class 3). Type B 
applications do not require AIR design approval or AEG evaluation and do not require DO-178B 
software development and certification. 

For Type B applications (and also anticipated for TASAR), the following responsibilities are 
identified for the various approvers and stakeholders in the approval process; 

FAA POI Responsibilities 

1. Verifies that; 

a) application criteria and operator requirements are met 

b) data updates follow maintenance manual and inspection program procedures 

c) applicable job aids, including human factors evaluation are completed 

d) training, checking, and currency programs are approved 


109 


e) operational evaluation report from operator is appropriately reviewed 

f) OpSpee or MSpec A061 is issued upon eompletion of authorization proeess, as applieable 

2. Ensures that the level of information integrity is commensurate with TASAR requirement - 

this is to be determined, but as noted, TASAR is anticipated to warrant a EEC of no more than 

“Minor”, and may even be of “No Effect” (refer to the “Analysis of TASAR Operational 

Hazards and Safety Requirements" [7]). 

Flight Standards Service (AFS) 

Flight Standards Service (AFS) provides initial operational authorization granted for hosted 
application(s) (e.g., performance and/or weight and balance applications) based on AIR 
recommendations and AEG determination of flight crew training, checking and currency 
requirements. 

Operator Requirements 

The Operator addresses the following requirements as part of the approval process: 

1 . Determines usage, architectural features, people, procedures, and equipment to eliminate, 
reduce, or control risks associated with an identified failure in a system 

2. Performs 6-month operational validation per authority granted in OpSpec or MSpec A061, 
as applicable 

3. Lises both EFB device / system and conventional paper copies during evaluation 

4. Submits final evaluation report to the POI, as appropriate after evaluation 

5. Operating system and hosted application software meet criteria for appropriate intended 
functions and do not provide false or hazardously misleading information 

6. Software revision loading will not corrupt data integrity of original software. 

Note: Depending on how the TASAR application will be integrated in a PED / EFB will dictate 
the level of partitioning required: 

1. If TASAR is standalone, with its own dedicated processor (own Operating System 
{0/S} and application software) and dedicated display, this is will not require any 
partitioning or special protections 

2. If TASAR has its own dedicated processor, but shares a common display with other 
“Approved Software” applications / software (per above definition), recommended Display 
Standards, e.g., AC 25-11, Electronic Flight Deck Displays (for Part 25 aircraft) [30], and 
AC 23.1311-1, Installation of Electronic Display in Part 23 Airplanes [31] must be 
followed 

3. If TASAR is hosted with other Approved Software applications in a shared processor, 
approved partitioning techniques must be followed. These techniques are required to 
guarantee throughput and resources (e.g., memory, hard drive, avionics data, etc.) of 
Approved Software applications. 

B.6 Principal Operations Inspector (POI) Review Checklists 

This section examines the items on the POI’s checklist used to review EFB applications. Guidance 
information for the POI checklist and review process is found in Flight Standards Information 
System (FSIMS) - 8900.1 Change 47, Vol. 4, Chapter 15 - EFB Operational Authorization 
Process [14]. 
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The following represent the high-level eategories addressed in the POI cheeklist review. This list 
of topics frames a much larger set of questions that may be asked by the POI to review and evaluate 
an EFB application to ensure that guidance documents, e.g. AC 120-76C are being followed by 
the applicant of the application to adhere to EFB standards requirements. In general the checklist 
questions are specific to initial installations and training for a given aircraft. This list of POI 
checklist questions is not repeated here due to their length, but can be found in [14]; four checklists 
are provided in Figures 4-79 to 4-82: 

1. Figure 4-79 represents Checklist 1, ’’Tabletop Electronic Flight Bag Evaluation 

2. Figure 4-80 represents Checklist 2, “Electronic Fight Bag Operational Evaluation” 

3. Figure 4-81 represents the “Evaluation Report Information Template” 

4. Figure 4-82 represents Checklist 4, “Electronic Flight Bag Fine Evaluation Job Aid”. 

The high-level POI checklist review for “General EFB” are as follows: 

A, General Considerations 

A first step is to research if any EFB hardware or software is covered by an existing Aircraft 
Evaluation Group (AEG) report by FAA AFS. If found, this can be used as an equivalent 
artifact(s) to expedite the approval process of the new application. 

The general consideration also focuses on workload of using the EFB application. 
Determination of whether an in-flight evaluation will be necessary is made, in the event 
that evaluation of the EFB application cannot be accomplished on the ground to 
demonstrate the intended function. (For TASAR, it should be acceptable to demonstrate 
the application on the ground rather than an in-flight evaluation, given an appropriate set 
of Use Cases / scenarios to demonstrate flight crew use of the TASAR EFB. However, 
NASA intends to perform research in flight simulators and in flight trials to assess flight 
crew performance using TASAR.) 

As part of the workload assessment, the POI will review the operator’s responses to the 
workload-related questions in Checklist 2 (as noted in Figure 4-80 in [14]. The POI will 
also verify that procedures are published and available to all EFB users and maintainers, 
that prefiight procedures and checklists are revised to include the EFB, and that procedures 
are established for EFB failures (e.g., single / dual EFB failures). 

B, Physical Placement 

This portion of the POI review process focuses on the design and placement of the 
“Structural Cradle” of the EFB mount. Numerous considerations are examined, e.g., 1) 
user procedures that specify location for EFB use and also stowage; 2) verification that 
EFB location does not a) obstruct visual or physical access to flight controls and/or 
displays; b) does not obstruct emergency egress path; c) provides security during flight; 3) 
mounting device a) documented per airworthiness documentation, b) locks in position 
easily, c) able to adjust to accommodate a range of pilot / flight crew preferences and 
physical abilities, d) is durable, and e) addresses crashworthiness considerations and 
restraint of EFB when in use. 

C, Training/Procedures Considerations 
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1) EFB documentation and policy: Verifies that a) written poliey adequately address each 
specific EFB application and that published AEG recommendations have been 
incorporated into the operator’s EFB program, b) procedures are in place to 
communicate upgrades of malfunctions of EFBs to users in a timely manner; c) EFB 
information from manufacturer is incorporated into operating procedures 

2) EFB Training: Verifies that a) initial EFB training includes evaluation of knowledge 
and skill requirements and include demonstration of key tasks; b) recurrent training 
includes evaluation of proficiency with the EFB; c) minimum training, checking, and 
currency requirements are specified; d) EFB training is customized to application being 
used. 

D. Validation Phase and Continued Data Collection 

1 ) This step verifies that a) the 6-month validation phase provides documentation by pilots 
/ users of the EFB of feedback about the EFB and its performance; and b) procedures 
specify the personnel responsible for EFB maintenance and database management. 

2) Also ensures that operator has an ongoing data collection and feedback / correction 
process that ensures suitability and reliability of data; ensures that data collection 
processes are in place and are factored into the operators Safety Management System 
(SMS). 

E. SMS Interface 

The SMS interfaced verifies that: 

1) Hazards associated with use and integration of the EFB have been identified, 
eliminated, or controlled, to an acceptable level through the life cycle. 

Hazards such as misuse, hazardous misleading information due to failure or 
malfunction, loss of information when needed, miscalculation, masking of information, 
confusion, corruption of data, excessive complexity of use, accidental damage, and 
human error in use, setup, and operation have been considered; 

2) Applicant’s SMS has procedures to mitigate identified hazards, e.g., availability, 
reliability of design, cross-checking of calculation/data, crew training, and misuse 
potential; 

3) Applicant’s SMS incorporates EFB hazard analysis, risk assessment and related safety 
reports. 

F. Software Considerations 

Verifies that procedures are established for testing software revision or database update 

prior to operational use. 

G. Hardware Considerations 

Verifies that: 

1) Display lighting and reflectivity has been evaluated for acceptability in each aircraft 
model; 
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2) EFB maintenance procedures are in place for batteries, displays, display interaction 
devices, display pixel burnout, and component condition. 

In addition to the above “General EFB” areas that the POI will review, the POI will also review 
the following areas, 1) Electronic Documents, 2) Electronic Check Lists, 3) Weight and Balance, 
Flight Performance calculations, 4) Electronic Charts. These areas are in reference to current Type 
A and Type B applications and are not specific to TASAR and are thus not addressed in additional 
detail. 

In addition to these above noted review categories, the POI will also assess the EFB Validation 
Phase. The POI will verify that procedures are established to collect user data for normal and 
abnormal EFB functions during the validation phase; also that the user provides a written report 
of reliability and problem resolution prior to authorization, e.g., for paperless operation (or other 
intended uses of the EFB application). 
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Appendix C Certification and Operational Approval Guidelines and 
Regulatory Requirements for TASAR; Project Specific Certification Plan 

Appendix C describes the 5 phases of a certification project as documented in “The FAA and 
Industry Guide to Product Certification (CPI Guide)” [28]. Section C.2 describes the Project 
Specific Certification Plan (PSCP) as applied to the TASAR EFB flight-deck application. Section 
C.3 represents a high-level Compliance Check List supporting the PSCP for TASAR. 

C.l Phases of Certification Project 

C.1.1 Conceptual Design (Phase 1) 

This phase is initiated when the applicant begins design concept for a product that may lead to a 
viable certification project. The intent is to ensure early, value added, joint involvement with an 
expectation to surface critical areas and the related regulatory issues, and begin formulating a 
preliminary PSCP. This is an opportunity to develop a mutual understanding of potential new projects. 

C.l. 1.1 Phase 1 Tasks 

• Early Eamiliarization Meetings on design concepts 

C.l. 1.2 Phase 1 Required Information 

• New designs, technology, materials, processes, etc. 

o Likely not applicable for TASAR 

• Proposed certification basis and means of compliance 

• Supplier relationships 

o TASAR EEB related hardware, software, data connectivity suppliers, if 
applicable/selected 

• Initial safety assessments 

C.l. 1.3 Phase 1 Deliverables 

Deliverables are prerequisites for subsequent phases and must be completed before entering the 
next phase, unless otherwise mutually agreed by the FAA and the applicant. 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 
milestones, and action item assignments 

• Preliminary certification basis considering the intended means of compliance, initial safety 
assessments, and relevant policy material and begin formulation of a PSCP 

o Identifies regulatory compliance required for the TASAR EFB application based 
on a “No Effect” or “Minor” failure effects designation 

Note: After meeting with EAA, TASAR will be designated as “Minor Effect” due to 
potential pilot workload associated with TASAR due to misleading /bad data 
(Section 4.3). 
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• Definition and plan for resolution of critical issues, e.g. new designs, technology or 
processes, potential special conditions, exemptions or equivalent safety findings, co- 
production or foreign supplier arrangements requiring undue burden assessments; etc. 

o Not expected to large extent for TASAR. TBD 

• Identify core team for commitment to developing the PSCP elements to ensure continuity 

• Phase I Evaluation Checklist (See Appendix VII of [28]). 

C.1.1.4 Phase 1 Criteria for Success 

• Commitment to the signed Partnership to Safety Plan (PSP) for the pending certification 
project. 

C.1.2 Requirements Definition (Phase 2) 

Efforts in this phase clarify the product definition and the associated risks, and conclude with a 
mutual commitment to move forward with product certification. Specific regulatory requirements 
and methods of compliance or critical issues are formulated. A more formal PSCP is developed. 

C.1.2. 1 Phase 2 Tasks 

• Meetings to refine product definition, requirements, and develop the PSCP 

• Preliminary Certification Board Meeting 

C.1.2.2 Phase 2 Required Information 

• Applicant’s descriptive design and production data 

• Critical issues definition 

• Refined safety assessments 

• Proposed schedule 

C.1.2. 3 Phase 2 Deliverables 

Deliverables are prerequisites for subsequent phases and must be completed before entering the 
next Phase, unless otherwise mutually agreed by the EAA and the applicant. 

• Submission of application, EAA Form 8110-12 (EAA Order 81 10.4) 

• Acknowledgment of application 

• Certification Project Notification (EAA Order 8 1 10.4) and establishment of project 

• Establishment of EAA and applicant project certification team 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 
milestones, and action item assignments 

• Preliminary PSCP including project milestones and related events such as program status 
reviews 

• Agreement of TC certification basis plan and definition of project issues such as means of 
compliance including special conditions, equivalent safety findings, exemptions, etc. 

• Phase II Evaluation Checklist (See Appendix VII of [28]) 
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C.1.2.4 Phase 2 Criteria for Success 

• Commit to the early development of the PSCP. 

C.1.3 Compliance Planning (Phase 3) 

During this phase a PSCP is completed. The plan is a tool to which the responsible parties commit 
and use to manage the product certification project. 

C.1.3.1 Phase 3 Tasks 

• Project planning and PSCP development meetings 

C.1.3.2 Phase 3 Required Information 

• Initial Failure Mode and Effects Analysis (FMEA)/Safety Assessments 

• Stakeholder identification 

• Refined critical issues 

• Production processes 

C.1.3.3 Phase 3 Deliverables 

Deliverables are prerequisites for subsequent Phases and must be completed before entering the 
next Phase, unless otherwise mutually agreed by the FAA and the applicant. 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 
milestones, and action item assignments 

• Signed PSCP 

• Project schedule with established FAA/applicant milestones for completion of analyses, 
test plan submission. Type Inspection Authorization (TIA), conformities, flight test, AEG 
evaluations, critical issues resolution plan, and other items affecting the completion of the 
project 

• Agreed Type Certification Basis 

• Compliance Check List 

• Completion of Stage 1 on all issue papers 

• Identification of stakeholders, including suppliers, installers in the case of engines, 
propellers, or systems, etc. 

• Delegations defined with oversight criteria 

• Resource requirements 

• Conformity procedures 

• Project evaluation measures 

• Phase III Evaluation Checklist (See Appendix VII [28]) 

C.1.3.4 Phase 3 Criteria for Success 

• Commit to agreement on the PSCP 
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C.1.4 Implementation (Phase 4) 

During this phase the applicant and FAA work closely in managing, refining, and achieving their 
agreed PSCP to ensure that all agreed upon product specific certification requirements are met. 

C.1.4.1 Phase 4 Tasks 

• Demonstration of compliance 

• Compliance and conformance requirements verification 

• Final Certification Board Meeting 

C.1.4.2 Phase 4 Required Information 

• Design and production analysis 

• Witnessing 

• Inspection results 

• Safety analysis 

C.1.4.3 Phase 4 Deliverables 

Deliverables are prerequisites for subsequent Phases and must be completed before entering the 
next Phase, unless otherwise mutually agreed by the FAA and the applicant. 

• Meeting minutes and correspondence to document decisions, agreements, and action item 
assignments 

• Meet milestones for completion of analyses, test plan submission, TIA, conformities, flight 
test, AEG evaluations, critical issues resolution plan, and other items affecting the 
completion of the project 

• Completed test plans/reports, conformity requests, inspections, and compliance 
documentation 

• Issue Papers, Special Conditions, Exemptions, Equivalent Safety Findings 

• Compliance and conformance findings 

• Type Design and Production approval issuance 

• Phase Evaluation IV Checklist (See Appendix VII of [28]) 

C.1.4.4 Phase 4 Criteria for Success 

• Manage to the PSCP 

• Conduct frequent project schedule and compliance checklist status reports, team and 
management reviews, and make revisions as needed to PSCP. 

C.1.5 Post Certification (Phase 5) 

During this phase close-out activities provide the foundation for continued airworthiness activities 
and certificate management for the remainder of the product’s life cycle. 

C.1.5.1 Phase 5 Tasks 

• Project follow-up and closure 

• Certificate management 
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C.1.5.2 Phase 5 Required Information 

• Airworthiness limitations 

• Maintenance and operations requirements 

• Project lessons learned 

• Relevant safety data 

• Type Certificate Data Sheet 

• Evaluation findings 

• Design change data 

C.1.5.3 Phase 5 Deliverables 

• Meeting minutes and correspondence to document decisions, agreements, schedules, 
milestones, and action item assignments 

• Compliance Summary Document 

• Type Inspection Report 

• Instructions for Continued Airworthiness 

• Continued Airworthiness Management Plan 

• Phase V Evaluation Checklist (See Appendix VII of [28]). 

Cl. 5.4 Phase 5 Criteria for Success 

• Work together for continuous improvement 

• Manage to the PSCP with a focus on continued operational safety 

• Provide proper levels of technical project and management leadership with frequent 
reviews to ensure project close-out to schedule and resolution of significant post-TC issues. 

C.2 PSCP with TASAR Content 

This section applies details of TASAR to the PSCP described in outline form in Section 4. 2. 3. 4. 
Before addressing the TASAR-specific content of the PSCP, Eigures C-1 and C-2 are provided 
from FAA Order 81 10.4C [27] that overview the Typical Type Certification Process (Figure C-1) 
and the Implementation Phase of this process (Figure C-2). In addition. Figure C-3 is provided 
from FAA Order 8900.1 CHG 47, Volume 4, Chapter 15 on the EFB Operational Authorization 
Process [14]. Figure C-3 illustrates the high-level interactions and activity flows between the FAA 
and the applicant as part of the product certification and approval process. 

The following is a more TASAR-specific version of a PSCP (the outline repeated from Section 
4.2.3.4). 

1) Purpose or Introduction 

This Project Specific Certification Plan (PSCP) represents the project plan intended to be used 
by the applicant (TBD name) and FAA for the certification and operational approval of the 
TASAR Electronic Flight Bag (EFB) system. TASAR is a Type B application to be installed 
in TBD aircraft using a Class 2 EFB (e.g., the Goodrich SmartDisplay™ EFB currently being 
used by the TASAR team for flight evaluation) along with an associated Aircraft Interface 
Device (AID) that provides read-only access to avionics such as the FMS, etc. 
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2) Description 

The following is a high-level application description of TASAR system as developed by the 
NASA TASAR team. 

TASAR is a flight deck-based Decision Support Tool, consisting of algorithms and automation 
processing, intended as an optional, advisory-only service (i.e., in the form of recommendations) 
to the pilot crew to seek trajectory improvement opportunities over the current flight plan. 
TASAR is expected to be hosted as an application on a portable Class 2 EFB as a Type B 
application. TASAR requires read-only access to avionics systems via an AID. In addition, the 
TASAR HMI [3], as currently defined does not make use of depiction of a map of the flight plan, 
own ship position, or other geo-referenced depictions of the external environment that may affect 
the flight plan. The TASAR HMI primarily offers recommended updates of proposed trajectory 
changes to be considered by the pilot for possible request of a change request to Air Traffic 
Control (ATC) to the current flight plan. 

Figure C-4 illustrates a high-level functional diagram of the TASAR application. Based on 
inputs provided by 1) the pilot (in the form of flight objectives and optimization criteria), 2) on- 
board avionics systems, and 3) via data link and network-enabled communications, the TASAR 
application computes available trajectory change request candidates that may improve the 
current flight plan. Trajectory change request candidates provided by TASAR are intended to 
have a relatively high probability of ATC approval if requested by the pilot, as TASAR seeks 
to provide conflict free recommended trajectory candidates that also anticipate ATC and 
airspace constraints. 
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Model of the Type Certification Process 



Figure C-1 Typical Type Certification (TC) Process 
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Figure C-2 Implementation Phase ofTC Process 
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Figure C-3 Approval/Acceptance Process Flow Diagram 
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Figure C-4 TASAR Functional Diagram 


The pilot has full discretion on the use of trajectory change request information provided 
by TASAR. They can choose to use TASAR recommended trajectory change request 
candidates as part of a change request to ATC, or they can choose to ignore them. TASAR 
can be manually inhibited at any time, for any reason. 

TASAR is a supplemental system intended to provide operational benefits, without 
adversely impacting safe operations and does not replace any aircraft systems or avionics 
functions required for flight operations. 

TASAR information sources are as follows: 

1. Own ship information, e.g., flight identification (Flight ID), aircraft state (position, 
velocity, altitude), guidance / Mode Control Panel settings, flight plan and intent 
information, cost index and performance information, etc. 

2. Other traffic information via ADS-B IN, TIS-B, and/or other available sources of traffic 
information, including aircraft state, and if available, intent information. 

Note: After meeting with FAA, it was indicated that TASAR is not an ADS-B IN 
application, but rather a performance/planning application that leverages ADS-B 
IN data, if available (Section 4.3). 

3. Air Traffic Management (ATM) system status and forecast (e.g., sector use, sector 
configuration. Traffic Management Initiatives, Special Use Airspace, etc.) 

4. Weather information (current and forecast) 

5 . Wind information (current and forecast) 
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6. Airline Operational Communications (AOC) / Flight Operations Center (FOC) 
information, including operator flight planning, preferences, objectives. 

TASAR is described in detail in the following documents currently under development by 
NASA and NASA contractors; Concept of Operations [1][2], and TAP Application 
Description [3]. An Operational Hazard Assessment of the TASAR intended function has 
been conducted [7]. Based on the above description of TASAR and its intended function, 
the TASAR Operational Hazard Assessment indicates that TASAR may be implemented 
with a “No Effects” FEC, with a worst case “Minor” EEC. With this level of safety 
requirement and the nature of TASAR application processing being well aligned with a 
Type B EEB software application, it is expected that certification and operational approval 
should be commensurate with prior EEB application approvals of similar type. 

Note: After meeting with EAA, TASAR will be designated as “Minor Effect” due to 
potential pilot workload associated with TASAR due to misleading / bad data 
(Section 4.3). 

3) FARs 

Section 7 provides a high-level Compliance Check Eist to the applicable Eederal Aviation 
Regulations (EARs) and associated regulatory and guidance documents from EAA for 
TASAR. No exemptions, equivalent levels of safety, or special conditions are anticipated 
for TASAR (to be verified). 

4) Compliance 

Compliance is expected to be shown by providing results from analyses (e.g. the 
Operational Safety Assessment), tests (e.g. non-interference testing of installed EEB 
components), documented results from the 6-month validation period, any conformity 
inspection results for the EEB mount, and review and demonstration of EEB use 
questionnaires of the intended function. At this point, no new and unique methodologies 
are expected to be used for TASAR, as this is expected to be closely aligned with 
certification approval of Type B applications. 

Refer to the Schedule in 12) below for reference to some of these deliverables. 

5) Conformity 

Installation of the EFB mount, aircraft power, and antennas to broadband wireless systems 
are likely candidates for conformity. Some of these components may be developed by 3'^‘* 
party vendors and will require testing and inspection, whether as part of conformity, or 
TBD other Compliance requirements. 

6) Data 

Refer to the Schedule in 12) below for reference to some of the data deliverables. 

7) Airplane Flight Manual (AFM) 

It is expected that a revision to the AFM or AFM supplement will be required for TASAR. 
This is TBD at this time. 

8) Type Certificate Data Sheet 

Indicate if this document is affected and how it will be revised. TBD. 
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9) Proposed DER(s) 

A TBD Designated Engineering Representative is expected to be FAA designee for the 
both the hardware and software aspects of the TASAR system. 

10) Master Minimum Equipment List (MMEL) 

TASAR does not affect the MMEL. 

11) System Criticality 

An Operational Hazard Assessment of the TASAR intended function has been conducted 
[7]. Based on the above description of TASAR and its intended function, the TASAR 
Operational Hazard Assessment indicates that TASAR may be implemented with a “No 
Effects” EEC, with a worst case “Minor” EEC. With this level of safety requirement and 
the nature of TASAR application processing being well aligned with a Type B EFB 
software application, it is expected that certification and operational approval should be 
commensurate with prior EFB application approvals of similar type. Refer to [7] for 
specific details on operational hazards and failure effects of TASAR. 

Note: After meeting with FAA, TASAR will be designated as “Minor Effect” due to 
potential pilot workload associated with TASAR due to misleading / bad data 
(Section 4.3). 

12) Schedule 

The PSCP schedule addresses the activities, milestones, and deliverables that guide the 
certification process from initial Type Certificate application by the applicant to the FAA 
until final certification approval is achieved. Several characteristics of the PSCP and 
associated process make it difficult to develop a detailed PSCP plan for TASAR at this 
time: 

• Engineering is an iterative process and thus requires multiple phases of effort 

• Few projects will traverse the time line from left to right 

• Planners work with limited information; as the project progresses, the plan should 
be kept flexible and revised as necessary 

It is at this point difficult to provide even a notional schedule for TASAR certification and 
operational approval. However, Figure C-1 (overall schedule view) and Figure C-2 
(implementation phase schedule view) presented in Section 6 provide a guidance of a 
general schedule with activities, milestones, and decision gates. 

The following is list of potential deliverables for TASAR: 

• Software documentation and demonstration 

Since software process and software development documentation do not require 
DO-178B for TASAR, documentation requirements are not excessive. A 
description of requirement based on the topics listed in Section 5.4 should be 
included. In addition, demonstration or proof of I) how TASAR does not adversely 
affect other applications that may be integrated in the same EFB, and 2) how 
software revision downloads ensure that operation of the application is not 
adversely affected. 
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• Drawings and specifications of “installed” components of the TASAR EFB (e.g., 
aircraft mount, power connection, data connection, antennas, etc.). Whether 
conformity inspections are required is TBD. 

• Airworthiness tests and results, e.g., electrical load testing of TASAR components 
with aircraft power sources, non-interference testing with avionics systems, etc. 

• Data that describes the product design for COTS and installed components. 
Electrical and mechanical performance data. Installation specifications. 

• Need for any special inspections (unlikely to be required for TASAR) 

• Any issues papers (none expected for TASAR at this time (TBD). 

The schedule must account for the various meetings that need to be conducted, including 
the Type Certification Board Meeting (TCBM) (not sure how many TCBMs may be 
required for TASAR due to the relatively small size of EFB certification projects), 
coordination meetings between the FAA and applicant engineers and other participants 
should be identified. Dates for tests and required participants for observing the test need to 
be scheduled. 

More specific information may be gained via an initial Informational and / or Pre- 
Certification Meeting with FAA representatives. Such a meeting(s) would include 1) a 
presentation of the high-level TASAR concept to FAA, 2) a joint dialog about the concept 
with some initial observations and notable points that may impact a future TASAR 
certification project, 3) guidance from FAA on expectation of a notional certification 
project for TASAR, and 4) input from FAA on documentation, tests (ground-based, flight 
test, etc.) and steps to be followed as part of a future certification project and subsequent 
approval. 
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C.3 Compliance Check List 

This section represents a high-level Compliance Check List supporting the PSCP for TASAR. 

C.3.1 Cornerstone EFB Documents 

The following represent the primary, higher-level documents supporting the certification basis of 
TASAR. Numerous additional documents representing the FARs, regulation, and guidance 
documents apply to provide the detailed EFB approval requirement. These lower-level but 
important requirements will be provided in a future report that documents the results of a “Dry 
Run” review with Designated Engineering Representatives (DER) of TASAR-related PSCP 
information. 

1) Title 14 of the Code of Eederal Regulations (14 CER) parts 21, 23, 25, 27, 29, 43, 91E, 
91K, 121, 125, and 135 [29] 

2) Elight Standards Information System (ESIMS) - 8900.1 Change 47, Vol. 4, Chapter 15 - 
EEB Operational Authorization Process [14] 

3) AC 120-76C, Guidelines for the Certification, Airworthiness, and Operational Approval of 
Electronic Elight Bag Computing Devices [13] 

4) AC 20-173, Installation of Electronic Elight Bag Components [16] 

5) EAA Order 81 10.4C, Type Certification [27] 

6) AC 21-16E, RTCA Document DO- 160 “Environmental Conditions and Test Procedures 
for Airborne Equipment” [17] 

7) AC 20-115, RTCA DO-178B, Software Considerations in Airborne Systems and 
Equipment Certification [20]. 

C.3. 2 Compliance Check List - High-level Items 

The following certification and operational approval compliance requirements for EEBs and 
associated software applications, with focus toward TASAR, are derived from FAA Order 8900.1 
Change 47, Vol. 4, Chapter 15 - “EFR Operational Authorization Process" [14]. This document 
represents the EAA Principal Investigators guidance for such approvals. In addition to these high- 
level requirements to achieve certification and operational approval for TASAR, there are 
numerous additional regulatory documents that provide specific details to these requirements. 
These more fine-grained requirements will be addressed in a future document of the DER “Dry 
Run” review of the TASAR certification process noted above. 

Note: The following references in the next section, e.g. “4-1643” refer to specific portions of 
EEB Operational Authorization Process document of EAA Order 8900.1 Change 47 [14]. 

C.3. 2.1 4-1643: EFB Hardware Classes 

B. Class 2 EEB (i.e., TASAR) 

• Typically mounted to the aircraft by a mounting device, may be connected to a data 
source, a hardwired power source, or an installed antenna 

o All these apply to TASAR 

• Represents a portable PED/EEB 
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o Must be located on the flight deck and controlled by the flight crew during all 
flight operations 

■ For TASAR, primarily used for en route, late stage of climb, early stage 
of descent 

o Must be accessible to the flight crew at all times and must be removable by a 
crew member without the use of tools 
o Attached to the aircraft via a mounting device 

■ Cockpit mount is likely choice for TASAR (yoke -mount should be 
avoided as this becomes a much more complex approval) 

o Components of the Class 2 EFB include all the hardware and software needed 
to support EFB intended functions (of TASAR) 

■ Portable EFBs are limited to hosting Type A and Type B software 
applications or TSO functions limited to “Minor” FEC 

• Airport Moving Map Display with own ship position is an 
exception to this as a “Major” application - can only be used for 
ground operations below 40 kts. 

o EFB may consist of modular components (e.g., computer processing unit, 
display, controls) 

■ Any EFB hardware not located on the flight deck and not accessible by 
the flight crew must be a certified installation via TC, amended TC, or 
STC. 

■ Any EFB hardware not accessible on the flight deck by the flight crew 
and/or not portable must be installed and certificated equipment covered 
by a TC, amended TC, or STC. 

• The one exception to being accessible on the flight deck is a 
remotely mounted antenna that provides signal reception to the 
EFB. 

• The AID falls into this category of being installed and requiring 
type certification. 

C.3.2.2 4-1 644: Hardware Specifications - Class 2 EFBs 

2. Major Class 2 EFB components (motherboards, processors, RM, video cards, hard drives, 
power supplies and connections) must be configuration controlled 

o Any changes will require reevaluation to demonstrate intended function still met 
■ Non-interference, reliability requirements still met 
o For sealed components use manufacturer model / part number 
A. Display considerations 

(likely TASAR requirements, TBD for input devices listed below) 
o Must meet Legibility requirements 
o Must meet Brightness requirements 
o Viewing Angle 

(see AC 120-76C, paragraph 10b(3) for important issues concerning viewing angle) 
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o Stylus, For a stylus screen, there must be an easily accessible stowage position for 
the stylus and an accessible spare stylus (or substitute stylus) must be available, 
o Digitizer Pen, When a digitizer pen is used to operate the EFB, the digitizer pen 
must have an easily accessible stowage position and be tethered. A spare digitizer 
must be immediately available and adjusted for use on each EFB. 

o Touch Screen, If a touch screen is used, it must be evaluated for ease of operation. 
The toueh screen must be responsive and not require multiple attempts to make a 
selection, but not be so sensitive that erroneous selections occur. 

B, Rapid Decompression (RD) Testing 

C, Electromagnetic Interference/Non-Interference Testing 
o Also for TASAR as a Transmitting PED (T-PED) 

D, Antennas airworthiness requirements 

E, Power Sources airworthiness requirements 

(TASAR likely to use aircraft power, hut not a firm requirement) 
o Battery primary 
o Battery maintenance 
o Aircraft secondary power 
o Aircraft primary power 

F, Data Connectivity (Class 2 Only) airworthiness requirements 

(required for TASAR) 

G, Data Loading/Datahase Changes airworthiness requirements (TBD for TASAR) 

o Class 1 or 2 EEBs must have a reliable means for revising the EFB databases 

■ Database currency is determined by what required aeronautical information 
the EFB is replacing 

■ Each method of data revision must ensure integrity of the data being loaded 
and not negatively impact the reliability of EFB operation 

■ Procedures must exist to protect the EFB from corruption, especially when 
internet and/or wireless means are used 

■ Database revision does not include application software or operating system 
changes 

■ Application software and/or operating system program changes must be 
controlled and tested prior to use in flight 

■ Database and/or application software changes may not be performed during 
operations (taxi, takeoff, in-flight, landing). 

Note: External drives for data loading are considered ancillary EFB 
equipment and not subject to specific requirements beyond those 
identified for data loading/database revision above. 

H, Mounting Devices (Class 2 Only) airworthiness requirement 

(likely required for TASAR) 
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o The EFB, when attaehed to its appropriately designed mounting device, must be 
evaluated to ensure operational suitability in all ground and flight operations and 
conditions (airborne use for TASAR) 

■ When attached to its mounting device, the EFB must not interfere with flight 
crew duties and must be easily and safely stowed when not in use 

■ The attached EFB must not obstruct flight crew primary and secondary 
fields of view (See AC 120-76C) 

■ The attached EFB must not impede safe egress. (See AC 120-76C) 

C.3.2.3 4-1645: EFB Software Specification 

Figure 4-77, Flowchart for Determining Electronic Flight Bag Software Application Type, is 
provided to aid in the determination of the EFB software application type. 

B, Type B, Type B applications are applications that are intended for use during critical 
phases of flight or have software and/or algorithms that must be tested for accuracy and 
reliability. AC 120-76C, Appendix 2 may be referred to for examples of Type B 
applications. 

TASAR is viewed to be a Type B application.. 

C. TypeC. These software applications are RTCA DO-178B, Software Considerations in 
Airborne Systems and Equipment Certification, compliant and require Aircraft 
Certification design approval. (NA for TASAR). 

C.3.2.4 4-1646: Operational Suitability Requirements 

Entry into aircraft records is required to add or remove installed elements (also for TASAR) 

The user/operator is responsible for ensuring that a Class 1 or Class 2 EFB, along with Type 
A and B applications, will reliably perform its intended function while not interfering with 
other aircraft equipment or operations. (Required for TASAR) 

A, Application Documentation. The user/operator must present application 
documentation to the POI demonstrating that the EFB meets its intended function. 

The attached flowcharts illustrated in Figure 4-75 and Figure 4-77 [14] will assist the 
user/operator with the identification and documentation of EFBs. 

Determining the operational suitability of a particular EFB is the responsibility of the 
user/operator and may be subject to specific guidelines from the applicable AEG 
reports. 

A. When an operator has completed the evaluation of a Class 1 or 2 EFB, the 
operator must submit an application requesting authorization to use the EFB 

The POI will review the application submitted by the operator and authorize/not 
authorize the use of the EFB based on the findings of the POI Review Checklist 
3, illustrated in Figure 4-78, POI Review Checklist [14]. 

2 ) When a new aircraft model is added to an existing EFB authorization, the 
suitability of the EFB for that aircraft must be addressed as part of aircraft 
conformity using this evaluation process. When a new EFB is added to an 
existing EFB authorization, the suitability of the new EFB must be addressed 
using this same evaluation process. 
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B, Operational Evaluation of Class 1 or 2 Hardware/Type A or B Software, The 

user/operator must evaluate the EFB for suitability of intended functions in each 
aircraft model. (TASAR requires avionics to support its intended function; depends on 
aircraft equipage) 

The user/operator must use the checklist as illustrated in Figure 4-79 [14], Checklist 1, 
Tabletop Flectronic Flight Bag Evaluation, to evaluate the operational suitability of the 
proposed EFB intended functions and aircraft model suitability. The intended functions 
of software applications must be appropriate to the individual aircraft make and model. 
(TASAR suitability). 

The user/operator should use the checklist shown in Figure 4-80, Checklist 2 Electronic 
Flight Bag Operational Evaluation, to develop a flight scenario for final EFB testing 
when initial EFB use is being evaluated 

Operators requesting initial EFB authorization must include their POI in the 
flight/simulator evaluation of an initial EFB implementation. 

Operational evaluations for subsequent additions of EFBs or aircraft models need not 
conduct flight/simulator evaluations provided intended functions remain substantively 
the same as previously evaluated EFBs. 

.2.5 4-1647: EFB Procedures. 

(Required for TASAR) 

The operator’s operations and maintenance procedures must be specific to each EFB and the 
operations conducted. 

The operator’s manual must identify each model of EFB authorized and each model of aircraft. 

A, EFB Configuration Control, (Required for TASAR) 

Standard EFB configuration control must be established and base-lined (i.e., initial 
hardware and software version at time of application) along with procedures to ensure 
that the EFB configuration control is maintained during system updates/revisions. 

Class 1 or 2 EFB configuration affects usability and battery life through setup of 
suspend/sleep modes. 

All classes of EFBs must have established standard operating procedures (SOP) to 
ensure reliable use of hardware and software. 

Procedures must be established for EFB database revision. This should include 
verification of continued intended function prior to use in flight operations following 
an EFB database revision. 

Note: Software updates, especially in the EFB operating system, must have 

extensive test procedures prior to use in flight operations. 

Software revision procedures must be comprehensive to ensure continued 
reliability of the EFB and verification of reliable intended function. 

B, Normal and Abnormal Operating Procedures, (Required for TASAR) 

1) Normal procedures for flight operations must be developed for all flight operations 
with EFBs. 

Prefiight must address battery charging, EFB database revision and data currency, 
EFB configuration control, and SOP for EFB setup. 
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In-flight procedures must include standard application operating procedures and 
EFB standard flight operating procedures for use. 

2) Abnormal procedures must be established to address likely EFB function failures. 
Procedures for single and dual EFB failure must be established. 

3) Class 1 or Class 2 EFB operating procedures and limitations must be established if 
the EFB being used has not demonstrated Rapid Decompression (RD) testing while 
on and operating. (See subparagraph 4-1644B above) 

4 ) Checklists must be established or revised to include normal and abnormal EFB 
procedures to be used by pilots in flight. This may be accomplished by amending 
checklists when approved operator-customized cockpit checklists are used or by 
creating an EFB checklist supplement when aircraft manufacturer cockpit 
checklists are used. 

C, Minimum Equipment List (MEL), 

(NA for TASAR; TASAR does not affect the MMEL) 

D, Maintenance, Regular maintenance procedures are required for Class 1 and 2 EFBs, 
including measures to ensure the continued readability of the viewing screen. EFB 
battery maintenance needs to be addressed to ensure battery life, change intervals, and 
safety. TBD if TASAR has any instructions for continued airworthiness (ICA). 

E, Risk Mitigation, Procedures must be established for a transition to paperless 
authorization. Initial procedures establish an independent backup during the EFB 
validation period. Procedures must be established for continuous reporting of problems 
with EFBs. There must be procedures in place for the user/operator to review these 
reports periodically to mitigate potential unreliability issues and correct operating 
procedures where necessary. Procedures must be established to notify flight crews of 
EFB problems or use issues. (For more information on risk mitigation, refer to Volume 
10, Chapter 1.) 

F, Training, The operator must develop EFB training for all personnel involved with EFB 
use, database servicing, and maintenance. EFB training must comply with training 
identified in AC 120-76C and be FAA-approved where applicable. 

Note; Training was noted as a requirement for approval of TASAR during the meeting 
with FAA. NASA noted that TASAR likely would require approximately 30 
minutes of training based on its relative complexity compared to other similar 
applications, e.g., the In-Trail Procedure application, which requires 30 minutes of 
training. FAA did not openly object with that estimate for training for TASAR (i.e., 
it is probably in the ball park of what is appropriate). 

C.3.2.6 4-1648: Airworthiness Requirements 

This paragraph outlines the airworthiness and return to service (RTS) requirements for 
installed components or provisions of Class 1 or Class 2 EFBs. These airworthiness 
requirements are applicable to all installed provisions capable of supporting EFB 
functions at flight crew stations, regardless of any other stated intended function. 

The installer remains responsible to ensure that all certification and airworthiness 
requirements are met for each installation. For provisional installations, each installer 
remains responsible for compliance with EFB airworthiness requirements, and each 
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operator is responsible for EFB operational use requirements of the installed provisions 
capability. All Class 3 EFB installations require certification under TC, amended TC, or 
STC prior to installation. 

Note: Per FAA feedback, for Class 2 EFBs, the only certification requirements would 
be for mounting / installation of the EFB, getting one-way, read-only access to 
certified systems data (e.g., via ARfNC 429 busses), and partitioning and 
protections for non-interference with certified systems. The AID is intended to 
accomplish much of this. FAA did not see the need for a PSCP for the TASAR 
software, just for the installation. If they already have an existing installation, 
then the operational approval process is for a user to go directly to their POL 

A, EFB Power Source, 

2) Class 2 EFB Power Source, 

(TASAR requirement is TBD) 

This is aircraft power used as the primary EFB power supply and requires the power 
supply to be hardwired or connected with certified connectors to ensure reliability. 

This is an EFB that continuously depends on connection to aircraft power to 
perform its intended function (no sustaining battery power) 

The aircraft power for Class 2 EFB power supplies must be designed to remain 
available at an acceptable level for required flight information, in the event of 
aircraft electrical malfunctions. 

Class 2 EFB power supplies require design approval by AIR under TC, amended 
TC, or STC, thus not eligible for field approval. 

B, EFB Data Connectivity, (TASAR requirement) 

This read-only data is provided to an EFB from the aircraft’s systems (e.g., flight 
management system (FMS), Global Positioning System (GPS), air data, fuel system) 
through a certified ARINC 429, RS-232, RS-485, or other compatible interfaces or 
certified router. 

EFB data connectivity does not include raw antenna reception data from an installed 
antenna going directly to the EFB. EFB data connectivity must include isolation to 
preclude the EFB from interfering with any aircraft system, and all associated wiring 
must be protected from damage and secured. EFB data connectivity requires design 
approval. Such design approval must be accomplished under TC, amended TC, or STC 
by AIR and excludes the installation from eligibility for field approval. 

Note: Data converters (e.g., ARINC 429 to RS-232) that are capable of 

supporting EFB functions at flight crew stations must have design 
approval issued by the FAA. 

C, EFB Mounting Devices, 

(For TASAR, avoid yoke mount as this is a flight-critical installation.) 
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2 ) Cockpit-mounted EFBs are Class 2 EFBs mounted in the cockpit other than on the 
control yoke. The EFB mounting device requires airworthiness approval by AIR. 
FAA policy excludes this installation from eligibility for field approval. 

D, Installed Antennas, (TBD for TASAR) 

Installed antennas are those antennas permanently installed in the aircraft. Portable 
antennas attached to a portable EFB, but not attached to the aircraft, are not subject to 
these airworthiness requirements. Portable antennas and temporary antenna holders, 
like suction cups, are subject to EFB evaluation requirements only. Installation of 
antennas capable of supporting EFB functions at flight crew stations must be 
accomplished using existing guidance for antenna airworthiness considerations. 

1 ) Antennas combining reception for both aircraft navigation and EFB must be TSO- 
approved for this intended function, providing isolation to preclude the EFB from 
interfering with antenna reception for aircraft navigation. 

2 ) ISO- or STC-approved antennas may be used to independently provide GPS and/or 
satellite weather for an EFB in accordance with existing installation airworthiness 
requirements. 

3 ) Portable EFB-only antennas without a TSO may be used to provide a GPS or 
satellite weather signal for EFB-only use. Non-interference testing by the installer 
is required. 

E, Installed Satellite Receivers (e,g,, Weather Radar (WX), XM Weather, WSI 

Inflight). (TBD for TASAR) 

If any component of a weather receiver is installed in an aircraft separate from a 
portable EFB on the flight deck, it is subject to avionics installation requirements and 
may not be considered a PED. If the result of the received weather data is capable of 
being displayed on an EFB, the individual components of the weather receiver system 
cannot be installed as STC provisions only because the installation cannot meet 14 CFR 
part 43 requirements for testing of non-interference without performing its intended 
function. (See the current edition of FAA Order 81 10.4, Type Certification, for more 
information on this subject.) The weather receiver must be non-interference tested with 
the intended EFB installed and operative even though the installation only applies to 
the weather receiver. The airworthiness for the weather receiver installation is 
independent of EFB/PED suitability responsibility of the user/operator. The 
user/operator is responsible for EFB non-interference as a PED and the installer is 
responsible for non-interference for the weather receiver as part of installation 
requirements. This installation requires design approval under TC, amended TC, or 
STC, which excludes the installation from eligibility for field approval. 

C.3.2.7 4-1649: Authorization Process. 

The operator is responsible to ensure that all operational requirements are met for an 
EFB. The operator must submit documentation demonstrating compliance with all 
operational requirements for EFBs to their POT The FAA evaluation process for an EFB 
follows the general process for approval and acceptance as described in Volume 3, 
Chapter 1. 
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A, Phase One - Initiation, Phase one of the process begins when the operator requests 
authorization to use the EFB from the FAA. During this phase, the FAA and the 
operator reach a common understanding of the role of the FAA and what documents 
and actions the operator is responsible for during each phase of the authorization 
process. 

B, Phase Two - Required Application Information. Phase two begins when the operator 
submits a formal FFB plan to the POI for evaluation. The plan is reviewed for 
completeness, and the POI facilitates coordination with other inspectors and FAA 
offices, as necessary. During phase two, the POI may coordinate with the appropriate 
AFG for guidance on FFBs that have functions not addressed in this guidance. Once 
the plan is accepted, the operator follows that plan to produce a complete FFB program. 
The operator must submit the following information in the application package: 

• EFB hardware and application specification (Figure 4-76) and Evaluation Report 
Information Template (Figure 4-81) [14] 

• EFB operator procedures/manual revisions 

• EFB cockpit procedures checklists 

• EFB training program 

• EFB evaluation report (Figure 4-79 and Figure 4-80) [14] 

• Rapid Decompression test data (when required) 

• Completed non-interference test results 

• Airworthiness documents for Class 2 equipment 

(mounting device, aircraft data connection, aircraft power primary, remote 
antenna). 

C, Phase Three — POI Review, The POI must use the checklist found in Figure 4- 
78 [14] to conduct a review of the application submitted by an operator. All POI 
specialties should coordinate the review of an operator’s EFB program. 

The POI should participate in the simulator evaluation or flight evaluation (TBD for 
TASAR) of an EFB when a user/operator is requesting initial EFB authorization. 

Additional simulator/flight evaluations are not required for adding a new EFB to an 
existing authorization unless there is a substantial change in EFB intended functions. 

When a new aircraft is added to a certificate with existing EFB authorization, the 
suitability of the EFB for that aircraft must be addressed as part of aircraft conformity 
and configuration control process. 

Inspectors should examine the technical content and quality of the proposed EFB 
program and other supporting documents and procedures. The user’s/operator’s 
program for EFB management is critical to EFB reliability (TBD for TASAR) and must 
be well documented for EFB users. 


135 


D, Phase Four - Temporary Authorization to Use an EFB, 

An interim EFB authorization is granted to allow the eertificate 
holder/operator/program manager to proceed with the required EFB 6-month 
operational validation testing. 

Note: The 6-month validation test formally begins when the certificate 

holder/operator/program manager is issued this A061 temporary 
authorization. Use Figure 4-82, Checklist 4 - Electronic Flight Bag Fine 
Evaluation Job Aid [14], for data collection during the validation phase. 
Validation testing should follow the guidelines in AC 120-76C. 

1) Unacceptable Validation Results, If the POI finds the proposed EFB reliability 
and/or function to be unacceptable by the conditions of this EFB guidance, then the 
POI should contact the operator for corrective action. EFB deficiencies must be 
corrected and the EFB function revalidated before proceeding to Phase Five. 

2) Acceptable Validation Results, If at the completion of the EFB 6-month 
validation test, the POI finds the proposed EFB reliability and/or function to be 
acceptable based on validation data, then the certificate holder/operator/program 
manager can proceed to phase five of the EFB A061 authorization process. 

E, Phase Five — Authorization to Use an EFB, The certificate holder/operator/program 
manager subject to regulations under 14 CFR parts 9 IK, 121, 125 (including 125 Fetter 
of Deviation Authority (FODA) holders (125)), and 135 is granted authorization to use 
an EFB through OpSpec/MSpec/FOA A061 after acceptable completion of validation 
testing in phase four. The POI will remove the “temporary authorization” annotated in 
the restrictions and limitations column of Table 1. Any subsequent change to EFB 
hardware or intended functions must be validated at a level appropriate to the effect of 
the change on the EFB program. 

C.3.2.8 POI Checklists for EFB Evaluations 

The following is a compressed version of the comprehensive questionnaires utilized by the FAA 
POI in reviewing the applicant’s EFB implementation and operational use. 

Note: Refer to Tables 4-79 through 4-82 in [14] for the detailed list of questions. 

Successful completion and acceptance to the responses to these questionnaires are an integral part 
of gaining approval of the TASAR EFB application. 

1 . Checklist 1 Tabletop Electronic Flight Bag Evaluation (Figure 4-79 in [14]) 

Checklist 1 contains a list of questions for operators to use during a tabletop evaluation of the EFB 
focusing on the EFB hardware and software applications. The checklist includes the following 
subtopics: 

• EFB Hardware 

• General User Interface 

• General Software Applications 

• Electronic Documents (If Applicable) 

• Electronic Charts (If Applicable) 

• Electronic Checklists (ECE) (If Applicable) 
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• Performance Calculations (If Applicable) 

After the operator has completed this checklist, the results should be documented so the POI can 
review the results with the operator. 

2. Checklist 2 — Electronic Flight Bag Operational Evaluation (Figure 4-80 in [14]) 

Checklist 2 contains a list of questions for operator consideration during an operational evaluation 
of the EFB, its documentation, procedures, and training. The first four pages contain questions that 
can be answered in a training or operational environment by pilots, instructor/evaluators, or other 
operational personnel. The last page contains sample crew performance questions that can be 
addressed in a simulation environment. 

After the operator has completed this checklist, the POI will review the results with the operator. 

• General EFB Hardware 

• Stowage (If Applicable) 

• Unsecured EFB (If Applicable) 

• General User Interface 

• Software Applications 

• EFB Procedures 

• Procedures for Keeping EFB Content/Data Current 

• Procedures for User Feedback 

• Procedures for Specific Applications (If Applicable) 

• EFB Training 

• Training for Charts (If Applicable) 

• Training for ECF Systems (If Applicable) 

• Training for Flight Performance Calculations (If Applicable). (NA for TASAR) 

• Crew Performance: Pre flight Planning 

• Crew Performance: Takeoff 

• Crew Performance: Cruise 

• Crew Performance: Descent 

• Crew Performance: Approach/Fanding 

• Crew Performance: Destination Ground Operations 

3. Checklist 3 — Evaluation Report Information Template (Figure 4-81 in [14]) 

This outline is used by the user/operator to ensure that the minimum content requirements of the 
evaluation report have been met. The format of the report is optional. However the information in 
the detailed questions must be included, as a minimum. 

4. Checklist 4 — EFB Line Evaluation Joh Aid (Figure 4-82 in [14]) 

This checklist is used for data collection during validation period. 

• Describe system configuration description and flight conditions 

• Overview questions concerning the main aspects to be assessed in validation period 

• General. 

• Electronic Charts, Documents, and Checklists. (NA for TASAR) 

• Flight Performance Data/Calculations (NA for TASAR). 
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• General Conelusions. 

The following approval signature and entry items are completed after reviewing the four 
checklists. Refer to [14] for details on these checklists. 

Assigned Aircraft: Date: Print Observer Name: 

Observer Signature: Certificate Number: 
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Appendix D DER "Dry Run" Review and Artifacts Details 

D.l D0-178B Objectives Artifacts Requirements for Level D 

This appendix provides a summary of the 28 objectives that must be satisfied for the DO-178B 
Level D software design assurance level for the various software development process steps. While 
TASAR does not required DO-178B to be applied for software approval, consideration should be 
given whether some elements of TASAR software should be developed to DAL Level D for 
possible future reuse in the event TASAR is upgraded and requires a more formal process. 

1) Software planning related - 2 objectives 

a. Software development and integral processes activities are defined 

b. Additional considerations are addressed 

2) Software development process related - 7 objectives 

a. High-level requirements are developed 

b. Derived high-level requirements are derived 

c. Software architecture is developed 

d. Low-level requirements are developed 

e. Derived low-level requirements are defined 
f Source code is developed 

g. Executable object code is produced and integrated in the target computer 

3) Verification of outputs of software requirements process - 3 objectives 

a. Software high-level requirements comply with system requirements 

b. High-level requirements are accurate and consistent 

c. High-level requirements are traceable to system requirements 

4) Verification of outputs of software design process - 1 objective 

a. Software partitioning integrity is confirmed 

5) Verification of outputs of software coding and integration processes - 0 objectives 

6) Testing of outputs of integration process - 3 objectives 

a. Executable object code complies with high-level requirements 

b. Executable object code is robust with high-level requirements 

c. Executable object code is compatible with target computer 

7) Verification of verification process results - 1 objective 

a. Test coverage of high-level requirements is achieved 

8) Software configuration management process - 6 objectives 

a. Configuration items are identified 

b. Baselines and traceability are established 

c. Problem reporting, change control, change review, and configuration status 
accounting are established 

d. Archive, retrieval, and release are established 
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e. Software load control is established 

f Software life cycle environment control is established 

9) Software Quality Assurance Process - 2 objectives 

a. Assurance is obtained that software development and integral processes comply 
with approved software plans and standards (with independence) 

b. Software conformity review is conducted (with independence) 

10) Certihcation Liaison Process - 3 objectives 

a. Communication and understanding between the applicant and certihcation 
authority is established 

b. The means of compliance is proposed and agreement with the Plan for Software 
Aspects of Certihcation is obtained 

c. Compliance substantiation is provided. 

As indicated, the above 28 objectives i.e., required activities to be performed, in item (8) above 
(with two objectives having independence requirements, i.e., where a second individual reviews 
the work of the person who created the original artifact) represent the Level D design assurance 
level as part of the software development process required by RTCA DO-178B. Table D-1 
provides a summary of ah levels of DO-178B in terms of the number of objectives and the extent 
of independence required. As is expected, the higher the design assurance level (Level A being the 
highest), the more intensive and rigorous will be the sohware development process. 

Note: While it is desirable to have the lowest design assurance level possible while meeting the 
safety requirements, the designer needs to consider what portions of the software 
development may need to be repeated at a future time at a higher design assurance level. 
In some cases, the designer may choose to develop portions of the software system to a 
more stringent design assurance level, allowing future reuse of such code. In the case of 
TASAR, it is not expected that DO-178B needs to be used in the software development 
process, and thus has a considerably reduced level of formal steps in its development. This 
would expedite the development and reduce the overall cost of the system. In the event 
TASAR functionality is upgraded in future applications, it is possible that a higher design 
assurance level may arise, requiring a redevelopment of the software to the higher-level of 
design assurance using the DO-178B objectives. 

Table D-1 Summary of DO-1 78B Objectives Required per Design Assurance Level 

Level Failure condition Objectives With independence 


A 


Catastrophic 


66 


25 


B 


Hazardous 


65 


14 


C 


Major 


57 


2 


D 


Minor 


28 


2 
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D.2 Tabletop EFB Evaluation (Detailed Check List #1) 

Note 1 : The following represents the detailed cheeklist utilized by the POI as part of the EFB 
Application approval process for the “Tabletop EFB Evaluation”. The list is taken from 
Figure 4-79 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 
Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and document- 
ation approval process for TASAR, it does not on its own address and achieve the actual 
certification and operational approval. Some observations are offered to assist this future 
process in looking through the list of questions provided in the Appendix. 


Tabletop Electronic Flight Bag Evaluation - Checklist 1 (Figure 4-79) [14] 


1 . If the EFB is to be used outside of the flight deck, can the EFB display be read under direct 
sunlight? 

□ No 

[El Yes 

While intended for cockpit use, it is conceivable that the pilot could access TASAR pre- 
flight to program and select the operational goals and objectives of how they want TASAR 
to support the upcoming flight. EFB use outside of the cockpit is not required but may be 
desirable for some users. 



2. Is the display brightness and contrast adjustable? 

□ No 

[El Yes 

3. Is the display brightness acceptable when it adjusts automatically? 

□ No 

[El Yes 

4. Are there any display artifacts such as jagged lines that impair functionality? 

[U No 

□ Yes 

NA 



5. Are controls labeled appropriately to describe their intended function? 

□ No 

[El Yes 

6. Are buttons and labels visible and readable under all flight deck illumination conditions? 

□ No 

[El Yes 

7. Can EFB inputs be made quickly and accurately in any operational environment? 

□ No 

[El Yes 

8. Does the input device provide sufficient tactile feedback in all environmental conditions? 

□ No 

[El Yes 

9. Are inadvertent or multiple activation of controls minimized? 

□ No 

[El Yes 

10. Does the EFB start up in a predictable state? 

□ No 

[El Yes 

1 1 . Can the EFB be rebooted when power is cut to the EFB? 

□ No 

□ Yes 

TBD. Should be able to be rebooted. 



12. Does the EFB function correctly when rebooted? 

□ No 

[El Yes 

13. Are all the EFB failure modes easy to see and identify? 

□ No 

[El Yes 

14. Is the failure annunciation/message appropriate for the EFB function that has failed? 

□ No 

[El Yes 

15. Are EFB recovery means easy to remember and apply when the EFB fails? 

□ No 

[El Yes 

Provide the Number and a Comment for Each EFB Hardware Question Checked as “No.” 
See above for each answer 


General User Interface 

16. Is the revision information and currency expiration date available and presented clearly? □ No H] Yes 
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17. Does the deviee respond immediately to user inputs? 

□ No 

[El Yes 

18. Is the proeessing speed always appropriate for normal use? 

□ No 

[El Yes 

19. Are appropriate busy or progress indieators displayed when proeessing is delayed? 

□ No 

[El Yes 

20. Is the user interfaee, ineluding funetions and navigation, eonsistent throughout the EFB? 

□ No 

[El Yes 

21. Is all information that is needed displayed and easily aeeessible? Is there missing or 
diffieult to find information? 

□ No 

[El Yes 

User interface provides access to all information relevant to TASAR with easy access. 



22. Are eommon aetions and time-eritieal funetions easy to aeeess? 

□ No 

[El Yes 

23. Are there standard ways to perform eommon aetions? 

□ No 

[El Yes 

24. Are the displays and eontrols used on the EFB similar aeross applieations? Are a eommon 
set of eontrols and graphieal elements used? 

□ No 

□ Yes 

The answer should be yes. At this point this project has addressed TASAR as a standalone 
application and has not examined how it may be integrated with other EFB applications. A 
windows-like operation between applications is possible or some equivalent means may be 
considered. Future actions required to address this question more specifically. 



25. Can all eolors be distinguished under the various lighting eonditions? 

□ No 

[El Yes 

26. Is eolor eoding implemented with a seeondary eode sueh as shading or highlighting when 
used to display eritieal information? 

□ No 

□ Yes 

TBD. TASAR on its own does not involve critical information. 



27. Are the eolors red and yellow used appropriately only for warnings and eautions? 

□ No 

□ Yes 

TBD. TASAR on its own does not require warning and cautions colors. 



28. Is the text easily readable? 

□ No 

[El Yes 

29. Do the eharaeters stand out against the display baekground? 

□ No 

[El Yes 

30. Are upper ease and italie text used infrequently? 

□ No 

[El Yes 

Actually this is TBD as part of the detailed design but the answer should be Yes. 



3 1 . Is text that may be used in low- visibility eonditions appropriate in size and easy to read? 

□ No 

[El Yes 

32. Is it easy to zoom in on text or graphies when they are too small? 

□ No 

[El Yes 

33. Is it obvious when information is out of view and ean it easily be brought into view? 

□ No 

[ElYes 

May be NAfor TASAR - TBD 



34. Is the spaeing between eharaeters appropriate? 

□ No 

[El Yes 

35. Is the vertieal spaeing between lines appropriate? 

□ No 

[El Yes 

36. Are ieons and symbols legible? 

□ No 

[ElYes 

37. Are ieon and symbol funetions obvious? 

□ No 

[El Yes 

38. Are the ieons and symbols distinguishable from one another? 

□ No 

[El Yes 
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39. Is each icon’s meaning explained by a label or other means? 

□ No 

[El Yes 


40. Are the EFB icons and symbols consistent with their paper equivalents? 

□ No 

□ Yes 


TASAR is not a paper replacement application - NA. 




4 1 . Do EFB alerts and reminders meet the requirements in the appropriate regulations as noted 
in the current edition of FAA Advisory Circular (AC) 120-76, Guidelines for the Certification, 
Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices, 
paragraph 10 (i.e.. The Human Factors Considerations for EFBs)? 

□ No 

□ Yes 


TASAR is not expected to require alerts and reminders. In the event a requirement for this 
arises it needs to be documented and meet the applicable requirement - NA or TBD. 




42. Are alerts and reminders consistent across all applications? 

□ No 

□ Yes 


TBD - see answers to24 and 41. 




43. Are alerts and reminders implemented so as not to distract? 

□ No 

□ Yes 


Should be if it becomes an issue. See answers to 24 and 41. 




44. Is there control over when, and whether, the audio or video is activated? 

□ No 

□ Yes 


TBD for TASAR. Answer should be yes if applicable. 




45. Is it easy to reset parameters to their default when they have been customized? 

□ No 

[El Yes 


46. Is EFB customization controlled through an administrative control process? 

□ No 

[El Yes 


Provide the Number and a Comment for Each General User Interface Question Checked as “No.” 
See above for each answer 






leneral Software Applications 




47. Can required information be found quickly and accurately within all applications? 

□ No 

[El Yes 

48. Is the information within applications organized consistently? 

□ No 

[El Yes 

49. Is information layout consistent with the paper equivalent? 

□ No 

□ Yes 


Paper replacement for TASAR is NA 




50. Is the layout of information appropriate for all applications? 

□ No 

[El Yes 

5 1 . Is high priority information easy to read? 

□ No 

[El Yes 

52. Is it easy to tell which application is currently open/active? 

□ No 

[El Yes 

Tc if OOCV7 f/~» cii7if/^Vi oi^i^lir»ofi/^Tic‘7 

1 1 
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54. Is extra acknowledgement required to open applications that are not flight related? 

□ No 

lElYes 


55. Do all open applications function as intended on an individual basis? 

□ No 

[El Yes 

56. Is access or links to related information appropriately supported? 

□ No 

[El Yes 

57. Are similar types of information accessed in the same way? 

□ No 

[El Yes 

58. Is it easy to return to the place where the user started from? 

□ No 

lElYes 


59. Is printing supported, and if so, is the hard copy usable? 

□ No 

□ Yes 
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NAfor TASAR 


60. Can a portion of a document be selected to be printed? □ No □ Yes 

NAfor TASAR 

61. Can a print job be terminated immediately? □ No □ Yes 

NAfor TASAR 


Provide the Number and a Comment for Each General Software Applications Question Checked as “No.” 

See above for each answer. Many answers assume multiple applications to coexist and thus provide anticipated use. 


Electronic Documents (If Applicable) 

62. Is it easy to tell where one is in relation to the full document? □ No 

□ Yes 

63. Is it easy to move between documents quickly? □ No 

□ Yes 

64. Is it easy to tell what document is currently in view? □ No 

□ Yes 

65. Is there a list of available documents to choose from? □ No 

□ Yes 

66. Is the document search function appropriate? □ No 

□ Yes 

67. Are tables, especially complex ones, readable and usable? □ No 

□ Yes 

68. Are figures readable and usable? □ No 

□ Yes 

Electronic Charts (If Applicable) 

69. Is there a way to pre-select specific charts for easy access during a particular flight? □ No 

□ Yes 

70. Is there more than one way to search for a chart? □ No 

□ Yes 

71. Is it easy to access charts when a last minute change is necessary? □ No 

□ Yes 

72. If the chart application uses aircraft location to facilitate access to charts, is this function 
appropriate (i.e., either approved by Aircraft Certification or explicitly allowed by AC 120- □ No 
76)? 

□ Yes 

73. Is it easy to switch between a decluttered and normal display if decluttering is supported? □ No 

□ Yes 

74. Is there a clear indication when any chart elements are suppressed? □ No 

□ Yes 

Provide the Number and a Comment for Each Electronic Documents and Charts Question Checked as “No.” 
Ouestions 62 thru 74 are NA for TASAR (not paper nor chart replacement) 


Electronic Checklists (ECL) (If Applicable) 

75. Are normal checklists available in the appropriate order of use? □ No 

□ Yes 

76. Can checklists be accessed individually for review or reference? □ No 

□ Yes 

77. During non-normal conditions, are relevant checklists easy to access? □ No 

□ Yes 

78. During non-normal conditions, does the device indicate which checklists and/or checklist ^ 
items are required and which are optional? 

□ Yes 

79. Is it clear where to find all checklists, whether on the EFB or on paper? □ No 

□ Yes 

80. Is the location of a paper document provided when it is referred to by the ECL? □ No 

□ Yes 
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8 1 . Does each checklist have a constantly visible title distinct from other checklists? 

□ No 

□ Yes 

82. Is it easy to select a checklist from a set of open checklists? 

□ No 

□ Yes 

83. Is there a reminder to review incomplete items when closing an incomplete checklist? 

□ No 

□ Yes 

84. Can an incomplete checklist be closed after acknowledging it is not complete? 

□ No 

□ Yes 

85. Does the ECL discourage two or more checklists from being used simultaneously? 

□ No 

□ Yes 

86. Is progress through the ECL clear? 

□ No 

□ Yes 

87. It is easy to reset the ECL to start over again? 

□ No 

□ Yes 

88. Does the checklist provide appropriate reminders for tasks that require a delayed action? 

□ No 

□ Yes 

89. Does the checklist clearly highlight decision branches? 

□ No 

□ Yes 

90. Can you return to the checklist from links or related information in one step? 

□ No 

□ Yes 

91. Is there an indicator of which item in the checklist you are working on? 

□ No 

□ Yes 

92. Is the checklist’s active item clearly indicated? 

□ No 

□ Yes 

93. Can the status of an item be easily changed? 

□ No 

□ Yes 

94. Does the next item automatically become active when the previous one is complete? 

□ No 

□ Yes 

95. Can the current item be deferred without completing it? 

□ No 

□ Yes 

96. Is it easy to view other items, even in a long checklist, without changing the active item? 

□ No 

□ Yes 

97. Is it easy to move between items within a checklist? 

□ No 

□ Yes 

98. Does the active item change to the next after an item is completed? 

□ No 

□ Yes 

99. Is there a clear indication that all items as well as the whole checklist are complete when 
finished? 

□ No 

□ Yes 

Provide the Number and a Comment for Each ECL Question Checked as “No.” 
Questions 75 thru 99 are NA for TASAR (not paper nor chart replacement) 


erformance Calculations (If Applicable) 

100. Does the device identify entries that have an incorrect format or type and does it generate 
an appropriate error message? 

□ No 

[El Yes 

101. Does the error message clarify the type and range of data expected? 

□ No 

[El Yes 

102. Are units for performance data clearly labeled? 

□ No 

[El Yes 

103. Do the labels used in the EFB match the language of other operator documents? 

□ No 

[El Yes 

104. Is all the information necessary for a given task presented together or easily accessible? 

□ No 

[El Yes 

105. Can the crews modify performance calculations easily, especially when making last 
minute changes? 

□ No 

[El Yes 

Il06. Are outdated results of performance calculations deleted when modifications are 

□ No 

[El Yes 


entered? 
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107. Does the display and/or crew training provide information to the crew on the 
assumptions on which the calculations are based? 

[El Yes 

108. Are crews trained to identify and review default values and assumptions about the 
aircraft status or environmental conditions? 

[ElYes 

109. Are the assumptions made about any calculation as clear to pilots as similar information ^ 
would be on a tabular chart? 

[El Yes 

Provide the Number and a Comment for Each Performance Calculations Question Checked as “No.” 

Note: The answers to the auestion in the above section are made in the spirit that while TASAR is not a 

Performance Calculation applications, the auestions are analogous to what mav be reauired for the TASAR 

pilot 

decision 

aid. 





[14] Checklist 1 contains a list of questions for operators to use during a tabletop evaluation of the Electronic Flight 
Bag (EFB) focusing on the EFB hardware and software applications. The checklist starts with EFB hardware 
questions, then presents general user interface questions, and ends with specific application questions (if applicable). 
The checklist is designed so that any question answered as “No” requires a comment that may include, “Not 
Applicable. ” - This approach is used in answering the questions below. After the operator has completed this 
checklist, the results should be documented so the POI can review the results with the operator. 
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D.3 EFB Operational Evaluation (Detailed Check List #2) 

Note 1 : The following represents the detailed checklist utilized by the POI as part of the EFB 
Application approval process for the “EFB Operational Evaluation.” The list is taken 
from Figure 4-80 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 
Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and document- 
ation approval process for TASAR, it does not in on its own address and achieve the 
actual certification and operational approval. Some observations are offered to assist this 
future process in looking through the list of questions provided in the Appendix. 

Checklist 2 — Electronic Flight Bag Operational Evaluation (Figure 4-80) [14] 

Checklist 2 contains a list of questions for operator consideration during an operational evaluation of the Electronic 
Flight Bag (EFB), its documentation, procedures, and training. The first four pages contain questions that can be 
answered in a training or operational environment by pilots, instructor/evaluators, or other operational personnel. The 
last page contains sample crew performance questions that can be addressed in a simulation environment. The 
checklist is designed such that any question answered as “No” requires a comment that in some cases may be “Not 
Applicable.” 


After the operator has completed this checklist, the POI will review the results with the operator. 

General EFB Hardware 


1 . Is there a backup source in the flight deck for EFB information? 
NAfor TASAR 

□ No 

□ Yes 

2. Is the EFB display readable under all typical flight-deck lighting conditions? 

□ No 

□ Yes 

3. Does each type of EFB failure have minimum impact to crew tasks and workload? 

□ No 

□ Yes 

4. Is the EFB installation appropriate for use in high workload phases of flight? 

Not expected to be an issue for TASAR. Primarily used en route and potentially during late 
portion of climb and early stage of descent, workload permitting. 

□ No 

□ Yes 

5. Are there appropriate Master Minimum Equipment List (MMEL)/minimum equipment list 
(MEL) items to handle EFB failures? 

TASAR does not affect MMEL as it is optional and not required to support flight operations. 

□ No 

□ Yes 

6. Have EFB failure items been incorporated into FAA-approved checklists? 

Not expected to be an issue for TASAR. More of a training issue to ignore /turn off TASAR 
if it unnecessarily distracts the pilot 

□ No 

[El Yes 

7. Does the EFB mount allow appropriate access to flight controls and displays? 

□ No 

[x] Yes 

8. Does the EFB mount allow appropriate access to the emergency egress path? 

□ No 

[x] Yes 

9. Are crews able to adjust and lock the EFB for optimal viewing? 

□ No 

[x] Yes 

10. Is there appropriate access to all flight controls during both ground and in-flight operations 
when the EFB is positioned for optimal viewing? 

□ No 

[x] Yes 

1 1 . Is there appropriate room to manipulate the EFB controls and to view its display? 

□ No 

[x] Yes 

12. Are all EFB hardware components that are routinely used easy to access? 

□ No 

[x] Yes 
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13. Are the EFB hardware eomponents usable and suitably durable for the flight deek? □ No [H] Yes 

Provide the Number and a Comment for Each General EFB Hardware Question Checked as “No.” 

See above for each answer, which are the anticipated outcomes resulting from the operational evaluation. 
Whether this requires a flisht test or if a ground test and demonstration is sufficient is TBD. It is anticipate that 
a ground test would be adequate vendins FAA apyrovals. 

S towage (If Applicable) 

14. Is there a stowage area for the EFB? □ No (El Yes 

15. Is the stowage seeuring mechanism simple to operate? □ No [El Yes 

16. Is the stowage securing mechanism unobtrusive when not in use? □ No [El Yes 

17. Does the stowage system allow appropriate access to flight controls/displays and egress □ No lEI Yes 
routes? 

18. Is the design of the stowage area acceptable? □ No lEI Yes 

19. Can the EFB be moved easily to and from the stowage area without blocking access to □ No lEI Yes 

flight displays/controls? 

20. Are the device and/or the stowage area unlikely to be damaged under normal use? □ No lEI Yes 

Unsecured EFB (If Applicable) 

21. Is there appropriate access to flight controls/displays when the unsecured EFB is in use? □ No EEl Yes 

22. Is there an acceptable place to put an unsecured EFB when in use? □ No lEl Yes 

23. Is there an acceptable place to put an unsecured EFB when not in use? □ No lEI Yes 

24. Can the kneeboard EFB be positioned such that the pilot has full control authority? □ No lEl Yes 

25. Is the kneeboard EFB comfortable for the pilot to wear under normal conditions? □ No EEl Yes 

Provide the Number and a Comment for Each Stowage and Unsecured EFB Question Checked as “No.” 

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 
appropriate implementation of TASAR. The exact nature of use mounted or unsecured are TBD at this time. Both 
should be acceptable. It is conjectured that due to the longer duration of en route operations, mounted use would 
be more desirable. 


General User Interface 

26. Is the workload using the EFB the same or less than the current process? □ No EEl Yes 

TASAR represents a new capability and is expected to be easily managed per proper design. 

27. Is the workload acceptable when there is an EFB failure? □ No lEI Yes 

In event EFB failure, TASAR operations are simply unavailable and terminated (unless a 
second EFB is available to choose to continue using TASAR. TASAR use is optional. 

28. Are other than critical EFB messages inhibited during high workload phases of flight? □ No EEl Yes 

TASAR use is at the discretion of the pilot. There is not an expectation for excessive messages 
from TASAR, but in the unanticipated event for this to occur, they are either ignored by the 
pilot (per training) or disabled. 
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29. Is the EFB user interfaee consistent with other flight deck systems? 


□ No [El Yes 


30. Does the EFB use terms, icons, colors and symbols consistent with other flight deck ^ 
systems? 

Software Applications 

[El Yes 

3 1 . Is the workload acceptable when configuring electronic charts while flying a procedure? □ No 
NAfor TASAR. 

□ Yes 

32. Does using the electronic checklist (ECL) produce the same crew actions that using the ^ 
paper equivalent would? 

NAfor TASAR 

□ Yes 


Provide the Number and a Comment for Each User Interface and Application Question Checked as “No.” 
See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 


EFB Procedures 


33. Are there procedures for starting up and shutting down the EFB? □ No 

[El Yes 

34. Are there appropriate procedures for all the EFB failure modes? □ No 

[El Yes 

35. Are there EFB procedures for when other aircraft system failures could render the EFB p. _ 
unusable? ^ 

[El Yes 

36. Are there procedures for using EFB backup information? □ No 

NA for TASAR as TASAR is optional. 

□ Yes 

37. Are there procedures to mitigate EFB workload? □ No 

TASAR is optional for use and via training, the pilot will disregard or disable TASAR if it 
affects workload in an adverse manner. 

[El Yes 

38. Are there procedures for establishing which source of information is primary? □ No 

TASAR information is used only for recommendations to the pilot and should not be used in 
lieu of other sources supporting flight operations. 

[El Yes 

39. Are there appropriate procedures for using EFB in high workload phases of flight? □ No 

TASAR is primarily intended for en route use or late part of climb segment and early stages 
of descent. If flight operations become high workload for any reasons, the pilot via training 
will cease to use TASAR until reduced workload allows pilot to choose to use TASAR again 
if desired. 

[El Yes 

40. Are there procedures that specify what data to use when data is redundant or different p. 
form the EFB? ° 

TASAR information is used only for recommendations to the pilot and should not be used in 
lieu of other sources supporting flight operations. 

[El Yes 

41 . Are there procedures for removal of a kneeboard EFB during emergency landing or egress p. .j,, 
(If Applicable)? ° 

[El Yes 

Provide the Number and a Comment for Each EFB Procedures Question Checked as “No.” 



149 








See above for each answer. The answers to the above are concevtual in nature and are expected to reflect an 
approvriate implementation of TASAR. 

Procedures for Keeping EFB Content/Data Current 

42. Are there proeedures to ensure data is aecurate and current for each software application? □ No EElYes 

43. Are changes to content/data appropriately documented? □ No [El Yes 

44. Are there procedures to notify crews of EFB updates? □ No EEl Yes 


45. Are there procedures to ensure that the correct information is installed when EFBs use 
information that is specific to the aircraft type or tail number? 


[H Yes 


46. Are operational control procedures consistent with regulations concerning preventative 
maintenance? 


□ No 


[HlYes 


TBD if applicable for TASAR. 


47. Is there a procedure to avoid cormption/errors during changes to the EFB device? □ No EEl Yes 


48. Is there a procedure to ensure that all EFBs have the appropriate content/data installed 
when there are multiple EFBs on the flight deck? 


[El Yes 


49. Is there a procedure to ensure that EFB data in use is approved for use in flight? □ No [El Yes 


50. Is there a procedure for when the database is not approved for use in flight? □ No EEl Yes 


51. Is there a procedure to ensure that all customized values are cleared from the EFB? □ No EElYes 

Procedures for User Feedback 

52. Is there a procedure for EFB users to provide feedback? □ No EEl Yes 


53. Is there a procedure for the operator to monitor feedback, correct EFB deficiencies, and/or □ No EEl Yes 
notify the EFB manufacturer? 

54. Are there procedures or built-in limits that prevent defining customized color schemes that □ No EEl Yes 
conflict with flight deck color conventions? 


55. Is there a policy regarding the use of supplemental audio and/or video in flight? □ No □ Yes 

NA for TASAR as currently defined. 

56. Is the EFB audio set to minimize any interference with higher priority communications? □ No □ Yes 

NA for TASAR as currently defined. 

P rocedures for Specific Applications (If Applicable) 

57. Are there specific policy/procedures for using the electronic charts application? □ No □ Yes 

NA for TASAR 


58. Does the policy specify what other EFB applications can be used while a procedure using ^ 
the electronic charts is actively being flown? 


NA for TASAR. However, with respect to TASAR, use of other applications is TBD but is 
considered feasible. 


59. Are there procedures on how to use the electronic charts when the EFB uses aircraft status 
data to configure chart elements? 


□ Yes 
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NA for TASAR. 


60. Are there proeedures to ensure that navigation/approaeh eharts required for the flight are 
installed and available? 

NA for TASAR. 


□ Yes 


61. Is there a procedure to identify the controlling copy of Weight and Balance (W&B)? 
NA for TASAR. 


□ No □ Yes 


62. Is there a procedure to establish responsibility for completion of W&B software? 
NA for TASAR. 


□ No 


□ Yes 


63. Are there procedures to maintain required W&B records? 
NA for TASAR. 


□ No □ Yes 


64. Is there a procedure to ensure that EFB performance data can be stored outside the EFB? □ No □ Yes 
NA for TASAR. 


Provide the Number and a Comment for Each of the above EFB Procedure Question Checked as “No.” 

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 


appropriate implementation of TASAR. 


EFB Training 


65. Are there appropriate EFB training, checking, and currency requirements? 


□ No 


[El Yes 


66. Does the EFB training program address all EFB intended functions and applications? □ No lH Yes 


67. Is there training on how to use unique features of the software applications? 


□ No 


lElYes 


68. Are crews proficient on the EFB at the completion of EFB training? 


□ No 


[El Yes 


69. Is EFB training customized for new users? 


□ No 


[El Yes 


70. Is the manufacturer’s EFB documentation sufficient? 


□ No 


[El Yes 


7 1 . Does the EFB training device provide an appropriate degree of fidelity when the actual 
EFB is not used? ° 

It is envisioned that the TASAR EFB applications also serves as the EFB training device. 


[El Yes 


72. Does the EFB training device simulate the key aspects of the task? 


□ No 


IE] Yes 


73. Does the EFB training appropriately address the meaning of icons and symbols? 
To the extent applicable to the TASAR user interface - TBD. 


□ No 


[El Yes 


Training for Charts (If Applicable) 


74. Is training on the use of electronic charts appropriate? 
NA for TASAR. 


□ No 


□ Yes 


75. Is there training on unique features of the electronic charts? 
NA for TASAR. 


□ No □ Yes 
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76. Is there training on differenees in map seale, orientation, and data quality between the ^ 
electronie charts and other flight deck displays? 

NA for TASAR. 

□ Yes 

77. Is there training on the limitations of own aircraft position when it is displayed? □ No 

NA for TASAR. 

□ Yes 

78. Is there training on policies pertaining to use of the electronic charts? □ No 

NA for TASAR. 

□ Yes 

79. Can crews use the electronic charts as well as paper charts? □ No 

NA for TASAR. 

□ Yes 

80. Can crews use the electronic charts to orient themselves and track their progress as they ^ 
fly required procedures? 

NA for TASAR. 

Training for ECL Systems (If Applicable) 

□ Yes 

8 1 . Is there appropriate training on how to use ECLs? □ No 

NA for TASAR. 

□ Yes 

82. Is there training on how to use unique features of the ECLs (e.g., how the EFB indicates ^ 
that a checklist item has been deferred)? 

NA for TASAR. 

□ Yes 

83. Is there training on which checklists are supported electronically and which are not? □ No 

NA for TASAR. 

□ Yes 

84. Is there training on the limitations of ECL automation when it uses aircraft status data? □ No 
NA for TASAR 

Training for Flight Performance Calcnlations (If Applicable). 

□ Yes 

85. Is there appropriate training on how and when to use the flight performance application? □ No 
NA for TASAR. 

□ Yes 

86. Is there training on critical performance calculation assumptions (e.g., runway length, p. 
W&B)? ° 

NA for TASAR. 

□ Yes 

87. Is there training to review default values for aircraft status and environmental conditions? □ No 
NA for TASAR. 

□ Yes 

88. Is there training on how to enter information required by the performance software? □ No 

NA for TASAR. 

□ Yes 

89. Is there training on how to interpret and use results of the flight performance calculations? □ No 

□ Yes 
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NA for TASAR. 

90. Is there training on where to obtain values when their normal sources are not available? □ No □ Yes 
NA for TASAR. 

91. Is there training on coordinating the roles of dispatchers and flight crews? □ No □ Yes 

NA for TASAR (from the perspective of flight performance calculation, which are not part of 
the TASAR concept. 

Provide the Number and a Comment for Each Training Question Checked as “No.” 

See above for each answer. The answers to the above are conceptual in nature and are expected to reflect an 
appropriate implementation of TASAR. 


Crew Performance: Preflight Planning 

Do crews with the EFB perform as well or better than crews with paper documents when — 


92. Calculating aircraft W&B, takeoff, climb, and maneuvering speeds? 
NA for TASAR. 

□ No 

□ Yes 

93. Crews maintain critical data for immediate reference? 
NA for TASAR. 

□ No 

□ Yes 

94. There is a runway change and a need to reference deicing fluid requirements or an MEL 
item? 

NA for TASAR. 

□ No 

□ Yes 


95. There are time critical adjustments prior to block out/taxi and takeoff? 

NA for TASAR. 

Crew Performance: Takeoff 

Do crews with the EFB perform as well or better than crews with paper documents when — 

□ No 

□ Yes 

96. There is a takeoff on a runway that requires briefing a special operator engine -out 
procedure? 

NA for TASAR. 

□ No 

□ Yes 

97. There is complex Standard Instrument Departure (SID) with an abnormal or an emergency 
during the departure climb-out? 

NA for TASAR. 

□ No 

□ Yes 

98. There is an emergency that requires a return to the departure or alternate departure airport? 
NA for TASAR. 

□ No 

□ Yes 

99. One EFB fails, requiring one pilot to rely on the EFB of the other pilot immediately after 
takeoff? 

NA for TASAR. 

□ No 

□ Yes 

Provide the Number and a Comment for Each Preflight and Takeoff Question Checked as “No.” 

The above questions are NA for TASAR 
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Crew Performance: Cruise 

Do crews with the EFB perform as well or better than crews with paper documents when — 

100. There is an engine failure/fire with possible condition of destination below weather „ . . „ 

mimmums ! 

NA for TASAR. 


101. There is electrical smoke in the cockpit requiring use of smoke mask/goggles while 
completing checklists or using EFB for approach briefing? 

NA for TASAR. 

Crew Performance: Descent 

Do crews with the EFB perform as well or better than crews with paper documents when — 


□ Yes 


102. There are conditions that require reference to Surface Movement Guidance and Control 
System (SMGCS) taxi routing or a complex clearance? 

NA for TASAR. 


□ Yes 


103. Reported runway conditions require reference to operational limitations? 

NA for TASAR. 

Crew Performance: Approach/Landing 

Do crews with the EFB perform as well or better than crews with paper documents when — 

□ No 

□ Yes 

104. There is mnway change or the need to re-compute landing weight and V speeds during 
approach? 

NA for TASAR. 

□ No 

□ Yes 

105. There are poor weather conditions or airports with complex taxi routes? 
NA for TASAR. 

□ No 

□ Yes 

106. There is a request for a specific taxiway turn during rollout after landing? 
NA for TASAR. 

□ No 

□ Yes 


Crew Performance: Destination Ground Operations 

Do crews with the EFB perform as well or better than crews with paper documents when — 

107. There is an EFB partial failure or erroneous output requiring maintenance discrepancy ^ ^ ygs 

to be entered? 

NA for TASAR. 

Provide the Number and a Comment for Each Crew Performance Question Checked as “No.” 

The above questions are NA for TASAR 
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D.4 EFB Report Information Template 

Note 1 : The following represents the detailed template used by the user / operator and reviewed 
by the POI for the information eaptured as part of the Evaluation Report. The list is taken 
from Figure 4-81 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 
Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and document- 
ation approval process for TASAR, it does not in on its own address and achieve the 
actual certification and operational approval. Some observations are offered to assist thi s 
future process in looking through the list of questions provided in the Appendix. 

Evaluation Report Information Template (Figure 4-81) [14] 

This outline is used by the user/operator to ensure that the minimum content requirements of the evaluation report 
have been met. The format of the report is optional, however the information below must have been included, as a 
minimum: 

1 . Electronic Flight Bag (EFB) evaluation identified by EFB make/model and aircraft make/model. 

While any number of Portable PEDs/EFBs, along with associated Aircraft Interface Devices, may be used 
for TASAR to provide the required Class 2 (or higher) EEB functionality, one particular EEB is being 
used by the TASAR research team for flight testing. The Goodrich SmartDisplay™ EEB and ARINC 828 
Aircraft Interface Device is a representative EEB for TASAR. 

2. The manufacturer’s name and model number of the mounting system evaluated. 

TBDfor TASAR. 

3. EFB location and stowage suitability. 

TBDfor TASAR. 

4. EFB display lighting and reflectivity. 

TBDfor TASAR. 

3. Suitability of procedures for EFB use during all phases of flight. 

Specific procedures for TASAR are TBD for this report. A pilot assessment of the use of the TASAR EEB 
application is part of other research currently being conducted by the TASAR team. 

4. Suitability of procedures to follow when one unit fails and when both units fail to include alternate means 
of accessing data. 

TASAR being optional, its use will cease in the event of failure of the EEBs. No procedures required to 
provide an alternate means or mitigation. 

5. A revision process procedure/method that ensures appropriate database accuracy and currency. 

TBDfor TASAR. 

6. Training effectiveness and typical acceptable training course completion. 
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TBDfor TASAR. 

9. Usability of each application (for example): 

a. Electronic documents’ functional suitability; 

NAfor TASAR. 

b. Aircraft performance, Weight and Balance (W&B), and speeds reference functional suitability; and 
NAfor TASAR. 

c. Electronic charts’ functional suitability. 

NAfor TASAR. 

10. Usability of multiple applications at one time. 

TBDfor TASAR. 

1 1 . Crew workload and currency for proficient use. 

TBDfor TASAR. 

5. Effectiveness of procedures that govern the distribution of application software updates to the aircraft and 
confirmation of the aircraft EFB configuration. 

TBDfor TASAR. 

6. Flight report — when and how reports of malfunctions or anomalies are reported and resolved. 

TBDfor TASAR. 
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D.5 EFB Line Evaluation Job Aid (Detailed Check List #4) 

Note 1 : The following represents the detailed ehecklist utilized by the POI as part of the EFB 
Application approval process for the “EFB Fine Evaluation”. The list is taken from 
Figure 4-82 in FAA Order 8900.1 Volume 4 “Aircraft Equipment and Operational 
Authorizations” [14]. 

Note 2: While this document provides information concerning the certification and document- 
ation approval process for TASAR, it does not in on its own address and achieve the 
actual certification and operational approval. Some observations are offered to assist thi s 
future process in looking through the list of questions provided in the Appendix. 

Checklist 4 — Electronic Flight Bag Line Evaluation Joh Aid (Figure 4-82) [14] 

USED FOR DATA COLLECTION DURING VALIDATION PERIOD 

This tool provides a starting point for Electronic Flight Bag (EFB) line operations evaluations. The questions are 
primarily designed to aid the POI but may also be useful to the operator for the collection of a structured set of 
observations about the use of the EFB before and during the 6-month validation phase. Use of this tool can be 
customized as appropriate for the situation. This is a final check to ensure that there are no problems with the EFB 
design/interface, training, or procedures prior to the authorization for use. 

The questions below encompass the operations and safety evaluation. In cases where a system shows weaknesses or 
limitations, mitigations must be developed in consultation with the applicant. 

In some cases, an EFB may add to the complexity of flight operations. The key questions to be answered are: 

1) Can the flight be conducted as safely with an EFB as with the methods/products it is intended to replace? 

2) Does the EFB add an unacceptable level of complexity for any critical activity or phase of flight? 

In order to answer these questions, it is helpful to consider more specific aspects of EFB usage, which are covered in 
Sections II through V below. Space is also provided in Section I to record general notes about the system and the 
evaluation. 

I. Describe system configuration description and flight conditions: 

Details of the TASAR system configuration sought for certification and operational approval will be determined 
once an applicant initiates this process and makes the appropriate design decisions to support their intended use 
to achieve operational benefits. TASAR may be implemented in a number of ways; as a standalone EFB 
application or may be integrated and operate concurrently with other EFB applications, in either a single or 
dual EFB system. 

The TASAR team will be conducting flight trials of the TASAR EFB prototype using a Piaggio Aero P180 Avanti 
test aircraft (per Engility and its AdvAero partner on the NASA TASAR research team). 

Currently, flight operations and flight trials will consist of several scenarios, based on short-term flight segments 
that will evaluate the TASAR concept (i.e., the Traffic Aware Planner (TAP) application). Several scenarios 
have been identified in initial planning: 

• Data Scenarios: designed to ensure that the TAP engine is receiving the correct data from the aircraft. 

• Functionality Scenarios: designed to exercise the TAP engine through each of its modes and capabilities. 

• Pilot Interaction Scenarios: designed to have the test subject exercise each of TAPs capabilities to gather 
subjective operational feedback on the capability and user interface, as it pertains to the in-flight 
environment. 

• ATC Interaction Scenarios: designed to have the test subject generate an optimization using TASAR, 
request the route change from ATC and, with the help of the safety pilot, execute the route change. 
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As currently envisioned, the TASAR Flight Trials will involve 10 flights based at Newport News/Williamsburg 
International Airport (KPHF) near NASA Langley Research Center. Each flight will be planned to fly a route 
as if en route to a destination. This destination will change from flight to flight to optimize the traffic and/or 
weather conditions for the given day. Approximately mid-way through the flight, the aircraft will be re-routed 
back to KPHF. 

The Pilot Interaction and ATC Interaction scenarios will be executed on flights 3-10. One new test subject is 
planned for each flight The test subject qualifications are to be a currently licensed IFR pilot with a valid 
medical, and to not have been involved in the TASAR project (for independence). 

During the approximately 120 minute period of each flight, the test subject will execute 11 scenarios, each 
exercising different TAP functionalities. The intention is to gather and demonstrate subjective feedback directly 
about each of the TAP functionalities. 

The final two scenarios involve generating a proposed route modification and coordinating it with ATC. One 
of these scenarios will involve a mock ATC operator in the cabin of the aircraft, and the second will involve a 
live ATC request, following through with execution of the request, if it is approved. Since it is not realistic for 
ATC to approve multiple requests for route changes through the course of a relatively short flight, the decision 
was made to hold off making any live ATC requests until after the other scenarios are complete, and following 
through if approved. 

While the test subject is performing the 11 scenarios, flight test engineers in the cabin of the aircraft will be 
performing functionality scenarios. These scenarios will put TAP through its paces using the scenarios being 
flown by the test subject. The intent here is to test TAP in various real-world operational scenarios, piggy- 
backing on the flight scenario being executed by the test subject This piggy-backing will be on a non- 
interference basis. 

Results such as those obtained from the described flight trials are expected to allow any necessary refinements 
to TASAR, but can also serve as flight evaluation results that could be offered to FAA in a future certification 
and operational approval process. 

Note: In addition to the flight trials noted above, additional research is planned to be conducted to evaluate pilot 
performance in a flight-deck simulator to assess and evaluate pilot performance in using the TASAR human- 
machine interface (to be conducted in the University of Iowa Operator Performance Laboratory {OPL}). In 
addition, NASA Langley is planning to perform part-task simulations of TASAR to further evaluate pilot 
workload and the effectiveness of TASAR. 

II. Overview. The main aspects to be assessed are encompassed by the following questions: 

1. Was training adequate to ensure that the pilot(s) eould perform in a safe and effieient 
manner? 

• Were individual pilot knowledge and skills adequate to allow normal eoordinated flight 
deek aetivities? 

• Was pilot knowledge regarding observed software applieations adequate? 

2. Are adequate proeedures in plaee to ensure that the EFB is integrated into the 
erew’s/operator’s system (e.g., normal and abnormal/emergeney operations and 
maintenanee funetions)? 

3. Was the EFB hardware or software adequate and appropriate during the flight? If there 
were any problems, partieularly in a eritieal phase of flight, deseribe in the notes spaee 
below. 

4. Could the pilot(s) reeover from usage errors without undue distraetion or diseussions? If 
usage errors were frequent or a distraetion, deseribe in notes below. 

5. Was the workload required for completing a task with the EFB equal to or less than the 
workload for completing the task with the conventional method? If no, specify phase of 


□n„D 


Yes 


EUnoCH Yes 

EUnoCH Yes 

EUnoCH Yes 
EUnoCH Yes 
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flight and task for any marginal or unacceptable increases in workload in notes space 
below. 

Describe any problems noted as “No” above: 


TBD for TASAR based on planned flight trials and assoeiated evaluations of pilot performance. 


III. General. 


6. Was each pilot able to use the cursor, track ball, touch screen, etc., for menu and □n„D 
functionality without frequent errors? 


7. 


Was the device appropriate and operational when exposed to environmental factors (e.g., □n„D 
turbulence, cold weather, vibration)? 

8. Was the device free of significant limitations in regard to display (e.g., off-axis view □n„D 
angles or various different lighting conditions)? 

• The device had easy and adequate dimming functions in low light (nighttime) 
conditions? 

• The device was adequately backlit and/or was viewable by flight deck lighting in low- 
light (nighttime) conditions? 

• The device was clearly visible in bright sunlight conditions? 

9. Was the device display clear (adequate resolution)? Confirm that the display was never □n„D 

misinterpreted because of viewing limitations. If so, record issues in notes space below. ® 

10. Did the pilot(s) ensure proper stowage and security (i.e., between flights, etc.) of the EFB □n„D 

per standard operating procedures (SOP)? Temperature limitations acknowledged? ® 

1 1 . Does the display continue to be usable after prolonged use in the flight deck environment I I 

(if applicable)? ' — ’ 


12 . 


Yes 


Yes 


Yes 


Normal functions (e.g., shutdown, startup) are adequate and do not require undue pilot | | | | 

attention or concern? 


13. Were procedures adequate for identifying currency of EFB data? 

14. Could the pilot(s) easily find and use required items and functions? 

15. Were the abbreviations and/or icons easy to understand? 


□n„D 

□noD 

□n„D 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


16. If multiple applications are supported, could the pilot(s) easily switch between critical I I I 
applications? ^ 


Yes 


17. If critical (e.g., abnormal or emergency checklists) applications are authorized in the EFB | | | | 

configuration basis, is their use at least equal to or better than previously approved 
methods? 


Yes 


□ 


18. The time to complete normal tasks was appropriate. 


□n„D 


N/A 
Yes 
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19. 


The audio features did not eause pilot distraetion and/or were 
for the flight deek environment. 


adjustable and appropriate CUnoIIII 


Yes 


□ 


N/A 


Describe any problems noted as “No” above: 

TBD for TASAR based on planned flight trials and assoeiated evaluations of pilot performance. 

IV. Electronic Charts, Documents, and Cbecklists. 

20. Were all neeessary doeuments (ineluding eharts, eheeklists, and manuals) found, 
identified, and easily viewed by the pilot(s) without undue distraetion? 

21. Was information eontained in electronie charts, documents, and checklists complete, 
equal in quality to previously provided products, and easily accessible and 
understandable? 

22. Was pilot knowledge of chart/document/checklist selection and viewing adequate? 

23 . Could the pilot(s) easily rearrange content on the screen to meet needs (e.g. , by zooming, 
panning, or otherwise customizing the view)? 

24. If printers are used, are printouts acceptable? 


□ noD 


Yes 


CUnoQ Y 


es 


□ noD V 


es 


□noD Yes 


CUnoHH y 


es 


25. 

26. 
27. 


28. 

29. 

30. 


Did the pilot(s) exhibit adequate knowledge of EFB functions to efficiently brief and fly 
required procedures? 


□noD 


Yes 


Did the pilot(s) exhibit adequate knowledge of the software revision process 
procedure/method that ensures appropriate database accuracy and currency? 


□noD 


Yes 


Did the pilot(s) exhibit adequate knowledge of contingency procedures? 
In the event of a failure of a single device. 
In the event that both devices fail. 


□noD 


Yes 


Were both pilots able to monitor necessary electronic chart displays during critical 
phases of flight? 


□noD 


Did the EFB allow quick entry of updates for last minute changes (e.g., flight 
plan/runway changes)? 


□n„D 


For electronic checklists (ECL), was it easy to track completed items? 


□n„D 


Yes 

Yes 

Yes 



Describe any problems noted as “No” above: 

TBD for TASAR based on planned flight trials and associated evaluations of pilot performance. 


V. Flight Performance Data/Calculations. 


31. Could the pilot(s) interpret and use flight performance data/calculations efficiently and 

accurately? 


Yes 
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32 . 


Did the device allow quick entry of updates for last minute 
plan/runway changes)? 


changes (e.g., flight y,, 



N/A 


33 . 


In the event that the Weight and Balance (W&B) and/or performance calculation 

I I ^Vl I I ^ Q 

software is not approved by the Aircraft Certification Office (AGO), all crewmembers 

are aware of the software’s limitations and understand that only approved calculation I I 

methods may be used as a primary means of computation. ' ' N/A 


Describe any problems noted as “No” above: 
NAfor TASAR. 


VI. General Conclusions. 



TBD for TASAR pending flight evaluation or ground demonstration as agreed to 
between applicant and FAA per Certification Plan. 


35 . 


Can the flight be conducted as safely with an EFB as with the methods/products it is 
intended to replace? 


□n„D 


Yes 


TBD for TASAR pending flight evaluation or ground demonstration as agreed to 
between applicant and FAA per Certification Plan. 


36 . 


Does the EFB add an unacceptable level of complexity for any critical activity or phase 

of flight? ' ' 


Yes 


TBD for TASAR pending flight evaluation or ground demonstration as agreed to 
between applicant and FAA per Certification Plan. 


Assigned Aircraft: Date: Print Observer Name: 

Observer Signature: Certificate Number: _ 
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Appendix E FAA T echnical Interchange Meeting Details 

This appendix provides details of the technical interchange discussions between the FAA team of 
EFB and ADS-B certification and operational approval experts and NASA TASAR research 
representatives (i.e., David Wing, the NASA TASAR Principal Investigator, and Steve Koczo, 
Rockwell Collins Principal Investigator supporting NASA in the TASAR certification and 
operational approval analyses). 

David Wing of the NASA Langley Research Center, Crew Systems and Avionics Operations 
Branch, and Steve Koczo of Rockwell Collins Advanced Technology Center traveled to 
Washington DC on July 24, 2013, to brief NASA’s TASAR concept and technology to FAA 
officials responsible for policy setting, certification, and operational approval of EFB (Electronic 
Elight Bag equipment, EFB software, and ADS-B (Automatic Dependent Surveillance-Broadcast) 
IN applications. The seven FAA officials described themselves as being “all the right people” for 
assessing the TASAR application from the perspectives of certification and operational approval. 

NASA TASAR concept for “Traffic Compatible Flight Optimization” received favorable FAA 
review. The outcome of the meeting was very successful, with widespread agreement of NASA’s 
and Rockwell Collins’ briefing materials and results from analyses, indicating TASAR has 
minimal certification and operational approval requirements. 

The FAA host for the meeting with the NASA TASAR team, and one of the key approvers of EFB 
applications from a flight standards and operational approval perspective, provided the following 
post-meeting exchange; “I want to thank you both for the presentation yesterday on TASAR. 
Overall, I believe the meeting was very productive. If you have any questions in the future, please 
do not hesitate to contact us. Also, if there's any confusion, when displaying this technology to 
stakeholders, on whether or not this is an EFB function, please let me know. I want to ensure that 
these performance calculations are considered EFB software applications. Thanks again for your 
great presentation.” 

As a major conclusion to the meeting, it was noted that existing policies already cover the proposed 
application, and an applicant (e.g. an airline) should have no difficulty getting approval to 
implement TASAR from their standpoint. This finding supports NASA’s objectives of developing 
a near-term, low-cost application for in-flight optimization of trajectories using ADS-B IN traffic 
data to increase the likelihood of approval. The application enables airspace users to gain early 
benefits of ADS-B IN at minimal investment risk, while also paving the way for the emergence of 
more advanced airborne surveillance applications with even greater operational benefits. 

The following represents major points and discussion results from the technical interchange: 

1. TASAR meets the definition of a Type B application and does not need to be added 
explicitly to the list of Type B applications in Appendix 2 of AC 120-76C [13]. Type B 
applications running on non-certified hardware (e.g.. Class 2 EFB) do not require DO- 
178B compliance. 

The FAA clearly considers TASAR a Type B software application (“performance 
applications”). They understood and agreed with the “Type B Lite” description although 
no such qualification is needed. It is not a problem that TASAR is not listed in AC 120- 
76C Appendix 2 (Type B applications), and it does not need to be added. 
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2. It was solidly agreed that TASAR is not considered an “ADS-B IN application” but rather 
a performance / planning application that leverages ADS-B IN data, if available. 

A key element in FAA’s view is that traffic is not displayed. AC 120-76B will soon have 
“Change 1” allowing own ship to be displayed on Type B applications on the airport 
surface only. 

3. No need was identified to establish a TASAR standard. 

Such a standard would have ensured that different avionics vendors would produce 
compatible TASAR systems, but they saw no benefit in this. 

4. TASAR should be viewed as a “Minor Effect” application because of potential pilot 
workload associated with TASAR due to misleading/bad data. From a loss of function 
standpoint, TASAR is viewed as “No Effect.” 

5. If an end user already has an existing EFB installation, then the operational approval 
process is for the user to go directly to the POI to demonstrate that TASAR is safe 
(including the workload issues) and provide a training program. 

David Wing offered a training estimate of 15 minutes for TASAR (using the In-Trail 
Procedure {ITP} of 30 minutes as a reference), which did not raise any objections. 

6. Existing policies already cover the proposed TASAR application. 

The following represents additional feedback, discussion points, and observations from the active 
discussions among all participants: 

• It was confirmed that TASAR software would not require DO-178B compliance. In fact, 
no certification of the TASAR software is required at all provided it resides on non- 
certified hardware (e.g. Class 2 EFB). 

• The only certification requirements would be mounting/installation of the EFB, getting 
one-way, read-only access to the certified systems data (e.g., via ARINC 429 busses), and 
partitioning and protections for non-interference with certified systems. The AID is 
intended to accomplish much of this partitioning/protection. 

It was noted that even a one-way, receive (read)-only connection could short an ARINC 
429 bus, but this can be managed. An applicant must show isolation and non-interference 
between the EFB and certified systems. 

• FAA did not see the need for a PSCP for the TASAR software, just for the installation. If 
they already have an existing installation, then the operational approval process is for a 
user to go directly to their POI. It may be worth talking to a POI about TASAR to better 
understand this process. 

The FAA host noted that our technical interchange meeting was in essence a “trial run” for 
how to conduct a meeting with all FAA involved (indicating that we had the right group 
together). 

• The whole idea of a “Class 3” EFB is going away. It will be considered an installed 
“Auxiliary Display”. 

For TASAR software installed on such a system, the software would be considered “Minor 
Effect” but would require DO-178B conformance (i.e.. Design Assurance Level “D”). 
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Asked whether new software is required or whether existing TASAR software (R&D code) 
could be certified, FAA indicated that existing code could still be used depending on how 
it was designed, developed and documented (i.e., the implication being that software was 
designed with DO-178B design objectives being considered up front). 

• FAA recommends using existing guidance for designing cockpit applications, e.g. human 
factors guidelines, and related to quality requirements of data. 

• If the EFB is to be shared by TASAR and other applications, human factors issues may 
need to be addressed regarding transferring back and forth, particularly if certified 
applications are involved. 

• The FAA certification authority on traffic surveillance asked whether TASAR would use 
TIS-B and TCAS traffic, and inquired on requirements for data content and accuracy. 

TIS-B has notoriously bad velocity data, and TCAS has none. Both also have limited range 
(TIS-B in particular). However a receiver can distinguish between and filter for only ADS- 
B data if desired. He recommended that we determine whether either of these systems 
would meet the performance requirements of TASAR. 

Somewhat related questions were raised on whether ground-based sources of traffic data 
(e.g. commercial sources) actually exist that could work, i.e. support TASAR. 

• It was recommended we talk with WSI about access to weather products. 

• The only other application using ADS-B IN data besides TASAR that does not employ a 
CDTI is TSAA (Traffic Situation Awareness with Alerts) which uses audio cueing rather 
than visual cueing. 

• FAA had no concern with TASAR’s map display on the “selected optimization” screen. 
Their only comment on the display was a preference to avoid use of yellow or amber if 
possible, as these are generally reserved for higher levels of hazard. 

• Benefit numbers from the NASA TASAR benefits study were viewed as very significant. 
FAA asked where the big hitter benefits arise from; we noted that wind route, weather 
(pop-up and when it dissipates) were key factors 

• It was suggested that TASAR could function in the General Aviation market without 
avionics connectivity (TBD). 

Potential areas of concerns and additional discussion items were noted for further consideration: 

• Some concerns were raised regarding whether TASAR solutions would be at odds with 
arrival flow planning and routing, particularly for Operational Evolution Plan (OEP) 
airports (i.e., largest 35 US airports) 

Destinations other than OEP airports were not viewed to be a problem. An open question 
is how TASAR would know the arrival constraints for a particular airport, e.g., an OEP 
airport. 

• EAA Plight Standards representative for traffic surveillance - could this (TASAR) lead to 
too many change requests to ATC? 

• EAA representative - what about future Trajectory Based Operations (TBO), i.e., point-to- 
point locations at specific times, will TASAR and TBO clash? 
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• Discussion about Top of Descent (TOD) and inward (i.e., approaching the terminal area), 
with future greater use of Optimum Profile Descent (OPD), Required Time of Arrival 
(RTA) at metering fix, FAA noted that TASAR may work for smaller airports but what 
about East Coast eorridor? David Wing noted that this is where use of constrained 
waypoint(s) would be in order for TASAR; also RTA 

• FAA made reference to the National Route Program (NRP), and that it is typieally 
discouraged to deviate from the NRP (implieation being how does this affeet TASAR use) 

• FAA eomment - “not one size fits all” with respeet to airspace operations, users, and 
implication of TASAR use 

• FAA asked about “throttle joekeying”, whether TASAR is reading the aetual fuel flow in 
making route optimization decisions (we answered we did not think so, but were not fully 
sure; this would be a question to be direeted to Engility in their algorithm design) 

• It was asked if we had talked to Air Traffie Controllers. We responded we had not. 

• FAA representative responsible for EFB certifieation made the following eomments - 
TASAR applieation is almost like a workstation; airlines will want to automate it, i.e., more 
data link, auto download to FMS 

o He also noted that the Air Traffic Organization should also consider a TASAR like 
tool for ATC, i.e., meaning looking/faetoring in data like weather, traffie, etc., in 
making route suggestions 

o Made a eomment about “making the gray line more solid”, with respect to EFB 
regulatory poliey and guidance 

o He also commented about bringing additional on-board displays into the eoekpit 
(implieation that this is an unwanted proliferation, e.g., pilots bringing PEDs on- 
board {perhaps multiple} for additional apps - suggesting some sort of integration 
of displays needs to occur to halt proliferation) 

Should not be second display - do not want to keep bringing on additional displays 

• The FAA host noted that POI is authorized to approve the EFB mount (which is not 
certified); while AID, which is certified, must follow AC 20-173 

• 2,200 OpsSpees are already in existenee, whieh ean be leveraged for future approval if they 
are equivalent to any new intended applieations. The referenees to these OpsSpees are for 
iOS and android type EFB applications 

• AC 120-76B Change 1 will be out before end of ealendar year 2013, will allow own ship 
on surfaee as a Type B application. Currently in signature cyele 

• FAA noted that FAS A (FAA’s certification counterpart in Europe) looks at EFBs as 
portable vs. installed; blaekening the line seeking to remove ambiguity. 

David Wing provided a brief demo of TASAR on the mobile prototype system that he brought to 
the meeting. The demonstration provided an exeellent view of the TASAR applieation and its 
intended use and was very well reeeived. 
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Acronyms 


AC 

Advisory Circular 

ACARS 

Aircraft Communications Addressing and Reporting System 

ACO 

Aireraft Certification Office 

ADS-B 

Automatic Dependent Surveillanee - Broadeast 

ADS-R 

Automatic Dependent Surveillanee - Rebroadcast 

AE 

Abnormal Event 

AEG 

Aireraft Evaluation Group 

AEM 

Airplane Flight Manual 

AES 

FAA Flight Standards Service 

AIAA 

American Institute of Aeronautics 

AID 

Aircraft Interface Deviee 

AIR 

FAA Aircraft Certification Service 

ALT 

Altitude 

AMMD 

Airport Moving Map Display 

AOC 

Airline Operational Communieations 

AOSP 

Airspace Operations and Safety Program 

ARMD 

Aeronautics Research Mission Directorate 

ARP 

Aerospace Recommended Practice 

ASA 

Aireraft Surveillanee Applications 

ASAS 

Aircraft Surveillance Applications System 

ASOR 

Allocation of Safety Objectives and (Safety) Requirements 

ASP 

Airspace Systems Program 

ASTC 

Amended Supplemental Type Certifieate 

ATC 

Air Traffic Control 

BC 

Basic Cause 

CCEP 

Coheetive Forecast Product 

CDTI 

Cockpit Display of Traffic Information 

CFR 

Code of Federal Regulations 

COTS 

Commereial of the Shelf 

CP 

Certification Plan 

CPDLC 

Controller Pilot Data Link Communication 
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CPI 

Certifieation Process Improvement 

CPP 

Certification Project Plan 

CR 

Contractor Report 

CTD 

Concept and Technology Development 

DAL 

Design Assurance Level 

DAR 

Designated Airworthiness Representative 

DCE 

Data Concentrator Emulator 

DER 

Designated Engineering Representative 

DMIR 

Designated Manufacturing Inspection Representative 

EASA 

European Aviation Safety Agency 

ECL 

Electronic Checklist 

ECON 

EMS Economy Setting 

EEB 

Electronic Elight Bag 

EMI 

Electro-Magnetic Interference 

EUROCAE 

European Organization for Civil Aviation Equipment 


EUROCONTROL European Organization for Civil Safety of Air Navigation 


EWINS 

Enhanced Weather Information System 

EAA 

Eederal Aviation Administration 

LANS 

Euture Air Navigation System 

EAR 

Eederal Aviation Regulation 

ECC 

Elight Control Computer 

EEC 

Eailure Effects Classification 

EMC 

Elight Management Computer 

EMEA 

Eailure Mode and Effects Analysis 

EMS 

Elight Management System 

EOC 

Elight Operations Center 

ESIMS 

Elight Standards Information System 

GAMA 

General Aviation Manufacturers Association 

GPS 

Global Positioning System 

HIRE 

High Intensity Radiated Fields 

HITE 

Human-in-the-Loop 

HMI 

Human Machine Interface 

ICA 

Instruction for Continued Airworthiness 
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IEEE 

Institute of Electrical and Electronic Engineers 

lER 

Instrument Elight Rules 

IIP 

In-Trail Procedure 

LED 

Light Emitting Diode 

EGA 

Letter of Authorization 

LODA 

Letter of Deviation Authority 

LVC 

Live Virtual Constructive 

MACS 

Multi-Aircraft Control System 

MCP 

Mode Control Panel 

MEL 

Minimum Equipment List 

MIDOS 

Manufacturing Inspection District Offices 

MMEL 

Master Minimum Equipment List 

MSpec 

Management Specification 

NASA 

National Aeronautics and Space Administration 

NOTAM 

Notice to Airmen 

NRA 

NASA Research Announcement 

NRP 

National Route Program 

NWS 

National Weather Service 

ODA 

Organizational Designation Authorization 

OE 

Operational Effect 

OEP 

Operational Evolution Plan 

OH 

Operational Hazard 

OHA 

Operational Hazard Assessment 

OPD 

Optimum Profile Descent 

OPE 

Operator Performance Laboratory 

OS 

Operating System 

OSA 

Operational Safety Assessment 

OSED 

Operational Service and Environment Definition 

OSR 

Operational Suitability Report 

PC 

Production Certificate 

PED 

Portable Electronic Device 

PIREP 

Pilot Reports 

PMA 

Parts Manufacturer Approval 
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POI 

PSCP 

PSP 

RD 

RF 

RTA 

RTCA 

RTS 

RVR 

SAE 

SC 

SID 

SMGCS 

SMS 

SO 

SOP 

SPD 

SPR 

ST 

STAP 

STC 

STI 

SUA 

SW 

T-PED 

TAP 

TASAR 

TAWS 

TBO 

TC 

TCAS 

TCBM 

TPM 


Principal Operations Inspector 

Project Specific Certification Plan 

Partnership to Safety Plan 

Rapid Decompression 

Radio Frequency 

Required Time of Arrival 

Radio Technical Commission for Aeronautics 

Return to Service 

Runway Visual Range 

Soeiety of Automotive Engineers 

Severity Class 

Standard Instrument Departure 

Surface Movement Guidanee and Control System 

Safety Management System 

Safety Objective 

Standard Operating Procedures 

Speed 

Safety Performance (and Interoperability) Requirements 
Safety Target 

Single Text Avionics Protocol 
Supplemental Type Certificate 
Scientific and Technical Information 
Special Use Airspace 
Software 

Transmitting Portable Electronic Device 

Traffie Aware Planner 

Traffic Aware Strategic Aircrew Requests 

Terrain Awareness and Warning System 

Trajectory Based Operations 

Type Certificate 

Traffie Alert Collision Avoidance System 
Type Certification Board Meeting 
Traffic Plow Management 
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TFR 

Temporary Flight Restriction 

TIA 

Type Inspection Authorization 

TIS 

Traffic Information Service 

TIS-B 

Traffic Information Service - Broadcast 

TOD 

Top of Descent 

TSAA 

Traffic Situation Awareness with Alerts 

TSO 

Technical Standard Order 

TSOA 

Technical Standard Order Authorization 

UAT 

Universal Access Transceiver 

UM 

Unit Member 

W&B 

Weight and Balance 

WPT 

Waypoint 

Wx 

Weather 

WxR 

(Airborne) Weather Radar 

XM 

Satellite Data Link Service Provider 
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